Post

14 followers Follow
3
Avatar

Populating hidden fields in webforms

Now that we can pre-populate fields of webforms via an edited weblink, the next logical progression is that we can populate HIDDEN app fields as part of a form submission, e.g. hiding a ID field or reference field so that records can be linked correctly behind the scenes...

Pete Cuff

Please sign in to leave a comment.

15 comments

1
Avatar

Hi Sara

This is what I need to do 

I need to create a web form that is linked to a CRM app item but not allow that to be edited / seen :

EG - We have a CRM app and an Order app

We will create the appropriate URL to customize the web form for each client 

They receive the order form (linked but hidden to their CRM item)

They fill in the order and submit 

We then have an order linked to the buyers CRM profile

Stuart Frodsham 1 vote
0
Avatar

Hi

I think this is a different request Sara.

I would like to prefill a field on a webform, but I would like that field to be hidden, so the user is not able to change it.

I believe this is not possible, as I am finding out now. Am I wrong?

Regards. 

Miguel 0 votes
0
Avatar

Hi Miguel,

I answered your support ticket earlier this week as well - you are right that it is not possible to pre-fill a field if it isn't enabled on the webform.

/Jacquelyn - Podio

Jacquelyn May 0 votes
0
Avatar

You could use a workflow (either podio or Globiflow) to enter a value into a field right after the item has been created trough the webform. This could be dependent on other variables in the form for example. Not exactly a pre-fill but I guess the effect is more or less the same? ID field can be created in Podio, relational stuff would require Globiflow in most instances I guess, depending on what you want to do exactly. 

Rutger Gernandt 0 votes
0
Avatar

@Rutger, not quite the same unfortunately as any data that is entered or even pre-populated in a webform can be changed accidentally or on purpose by the submitter no matter what you do.  I need to be able to send someone a webform link say where there's a hidden field that lets me track which website it's come from, or which person it relates to (e.g. like a referrer code) or many other use cases.  In all of these use cases though, I fdon't want the person filling out the form to know or see that detail, I just need to receive it in order for me to be able to run processes off the back of it.

Pete Cuff 0 votes
0
Avatar

@Pete: hmm I do not entirely seem to understand your use-case, but maybe that is because I am thinking in a different direction for a solution. To be sure we are talking webforms here, right? Because for users within Podio it is different of course, and I actually bumped into this thread because rumour is out that an Always Hidden Field option in Podio is in beta actually (which is great news for the kind of use-case where you want a relationship field to be populated by an automated flow but you don't want the end-user within Podio to see it (because of screen clutter and the like), but that seems a different thing than you talk about). 

 

If we are talking webforms my suggested solution would be:
1. webform is filled in, only fields to be filled in are shown in the form on the website (as is possible to select in the webform editor)
2. the webform is completed which triggers the creation of an item in a Podio app with the info filled in.
[2b. No editing though the webform can be done after this point, or you have to give them a guest account (which is the way to go if you want this kind of dynamic interaction) or use a third party portal]
3. populate the fields hidden on the website in the item with a workflow or (globi) flow Triggered Upon Creation and use Update Item (here) to fill out these fields automatically. For example the relationship field could be filled with a relation to a current person in your CRM database app (but conditional on a sanity check for the case that it already exists), this is possible through Globiflow. A refer code could be created in the same manner for example be merging fields that are pulling in the unique code with the use of the @xxx variable option, this is also possible in Podio but has some limitations to which fields you can use. The use-case of filling in which website the entry is done from is a bit more difficult I guess. 

(this can also solve Stuarts use-case actually, although this does require Globiflow)

Rutger Gernandt 0 votes
1
Avatar

@Rutger, yes an always hidden field option is in late beta at the moment (I'm in the test group and a Podio Partner).  This is a huge step in the right direction but isn't my use case.

My use case is I want to send you a form, potentially thousands of people an entirely blank webform and be able to track it back with a unique identifier or similar so that I can process correctly if and when you complete it.  I could be using the same form for many different types of thing, and I wouldn't want to have one app per type of thing (e.g. an app for tracking website X submissions, an app for tracking email campaign Y submissions, an app for tracking email footer Z submissions): I want them all to come to one place and for the submitter to be none the wiser - a bit like a tracking pixel in a website/image.

For this to be true, I would want the webform being completed to have - in effect - a field that I can prepopulate intelligently via the URL I give them (see here) but I don't want them to see that pre-populated field, I just want to receive that data back again IF they complete the form.

Seems like others earlier in this support thread were also looking for the same functionality so don't think it's just me hoping for this function.

Pete Cuff 1 vote
1
Avatar

Pete,
On one of my globiflow external link pages, I have a jotform with hidden fields and use globiflow tokens to fill them. This jotform pushes to globiflow webhooks flow. I think this setup would meet your need for fillable URL and hidden fields.
The downside to this setup is that changes to the app structure have to be updated at jotform and at podio.

Would this work?

Mike Davis 1 vote
1
Avatar

@Mike thanks yes this kind of setup can work but as you will agree it's a rather convoluted process to what is otherwise a relatively straight forward feature request (which lest we forget is why I created this item here)!  One can use another form provider to capture the data that DOES support the idea of hidden fields: all I'm asking is for Podio to include that technology in their webforms too!

Thanks again

Pete Cuff 1 vote
1
Avatar

Ah yes in that case I get what you mean, and I by now also understand that you are not a novice to Podio. There is an interesting question of design philosophy question/debate & user communication behind it I think. 

This is especially relevant with a platform like Podio with a functionality that spreads out so width and has quite a large user group. If you are aiming for the "80%" overall, there is quite a significant group of users for whom a specific functionality is firmly within the "80% range". But at the same time, like with statistics analytically the effect size is more important then significance, i.e. for all users together it is not such an important feature. 

Generally I think it is less of a problem nowadays, with all software developed with an API basically out of the box on most development platforms, it is possible to use multiple tools together more or less seamlessly everywhere. You don't need a piece of software anymore that covers all uses even if you want it all to be integrated. This is great because it means that a focus in development of a functionality can be more focused and there can be more pluriformity. However two problems do pop up I experience (also in my own experience as managing director of a theatre company): implementing problems/friction because users have to work with a lot of different interfaces across your 'suite' of software tools and the TCO goes up sharply if tools are to specific and do not have enough breadth. (I think the fact that Podio is offering software of third parties included with its own tool is quite an interesting development in this respect for the second point. It is a risk too because functionality your users will depend on is developed by 'others', but it is also a very interesting step I think. It also needs some thinking still, because of point one for example (maybe release your artwork and design features in semi-public domain for example? Almost like a framework? Then you tease out more uniformity perhaps), but very interesting nonetheless). 

I have seen Podio grow into a really amazing tool from when I created the first organisation in March 2011 (I think just after the official launch or just before it?). The functionality, especially of the 'new' calculation fields combined at the background with Globiflow, actually still quite amazes me. Together you can build in really a lot of functionality that would costs tens of thousands of euros if I would need to hire a developer(s) for this. However during this whole period I also noticed there was an annoyance (also with myself) about the seemingly lack of a roadmap for Podio. And this use-case also seems an example of it. While I totally understand your need for it, probably the honest answer from a Podio perspective in this case would be, that this is so specific that you should look for a third party solution and use Podio for other things.

I have the feeling that if Podio is able to formulate more clearly in it's communication (also public) what it is actually not doing and why, this would increase using satisfaction overall quite a lot. And also make acceptance easier because as humans we just need solid justifications. Basically a matter of positioning it more as a platform that can do a lot, but not everything and open to external solutions. Even though this is a really difficult thing, because people should still try and not back down even if No is the answer. I mean you as a podio developer will try something, a lot of people using it are not developers and they are the core user group. Some solutions in Podio are makeshifts, but they do work. And according to the 80% yardstick they are really in the ballpark. All in all a difficult dilemma, but generally I think more transparency about this (and a roadmap) would be good (I am also part of the beta group actually, which is obviously a more internal group already which you can see in the tone of voice). It will create extra work explaining the obvious to quite some users, but to paraphrase Locke that should only make your argument more obvious because it invokes self-criticism about things you did not think about for too long. (Just a very small example: somebody I introduced to Podio asked me about a completely obsolete page in mailchimp about syncing lists. Why is it still there?)

Anyway sorry for all this mumbling. Just melancholic I guess! ;) I really hope you manage to pull of a good solution for your clients. Actually the idea of sending out form in this way already triggers some thoughts with me as well on audience interaction, that could be really interesting! 

Rutger Gernandt 1 vote
2
Avatar

@pete this is exactly what I'm looking for in a solution. Have even tried adjusting in the CSS but it seems that the CSS code for read-only is being stripped. 

Surely it wouldn't be hard to add an option button in the fields which allow the user to create a read-only field, which updates the input type in the HTML.  Just my 2 cents. 

<input type="text" value="3" class="field left" readonly>

Screen shot https://cl.ly/ce4d122d7081

 

If anyone has work around to this solution I would love to hear. As would like to follow the same process as Pete raised. 

James D Hayward 2 votes
1
Avatar

Anyone figure out how to do this yet?  I need to pass a hidden field and value within the webform so that I know where it came from.

David Ounanian 1 vote
1
Avatar

Everyone! I was able to do this!!!!

So my need was to populate a prefilled in the link to our customer with an order id, but not show that field in the webform.

This order ID links back to our orders, so i didnt need them to see/change it!

This is made possible by using the custom CSS, i was able to hide the label and the field, while still having it populated on submission.

My Field Type : text
My Field External_ID : title

First code hides the actual field.

Second code hides the label. 

.webforms input[type="text"][name="fields[title]"] {
display: none;
}
label[class="webforms__label"][for="title"] {
display: none;
}

Steven Lawson 1 vote