General Discussion

Hello All Community members, I am curious to understand how your organization has structured/named your ProntoForms FormSpaces?  ProntoForms Staff, what have you seen with customers you may have worked with in the past? 

We could have used a poll for this but wanted to give you a chance to comment. (Please do not post your actual FormSpace names, ProntoForms Staff - no customer names) Industry vertical may be interesting to include if there is something unique to that Industry.

Do you use a variation of one of the following (or any combinations or variations):

1. Production / Development / Sandbox
2. Geographical Region
3. By Internal Role or Function
4. Form Language
5.  .... or something else (feel free to describe)

------------------------------
Stu Rathbone
Program Manager ~ Knowledge, Training & Enablement
ProntoForms
community@prontoforms.com
------------------------------

Hey Stu, 

In my experience with this sort of thing, I have seen many examples of each of the items you outlined and it really depends on how your forms are being filled out and by whom. 

You will either go with Production / UAT (User Acceptance Testing) / Development, where you will build your forms in Development (do some light testing), move the form over to UAT and get it in the hands of the people who will be filling the form out on a regular basis and get their feedback (making changes to the DEV form and pushing it back over to UAT with a few changes) and then once you are happy with that, copy it over to Production for the rest of your users. 

The other way I have seen it, but more predominantly with Construction companies, is to split up the forms based on who is filling them out. For example, in a lot of cases you've got a Foreperson and a Superintendent who will need to be filling out different forms. In that case, I would have a Foreperson formspace and a Superintendent formspace (With an equivalent DEV and TEST formspace).

Geographical locations do come into play also as they might be using different data sources for the forms of different regions, but this could also be accomplished using Data Partitioning in the same formspace.

To summarize, I would say that the most basic requirements would go with a Prod/UAT/Dev set up, adding more as the requirements grow; whether its language, region or even hair colour. 

Hope this helps!

Thank you 

------------------------------
Ian Chamberlain
Implementation Specialist
ProntoForms
------------------------------

Hi Stu and Ian,

We have our forms split into Job specific FormSpaces, plus 1 for Development.

------------------------------
Lisa Zido
Technical Systems Analyst
GOJO Industries Inc.
------------------------------

Original Message:
Sent: 03-24-2022 14:44
From: Ian Chamberlain
Subject: FormSpace Structure/Naming

Hey Stu, 

In my experience with this sort of thing, I have seen many examples of each of the items you outlined and it really depends on how your forms are being filled out and by whom. 

You will either go with Production / UAT (User Acceptance Testing) / Development, where you will build your forms in Development (do some light testing), move the form over to UAT and get it in the hands of the people who will be filling the form out on a regular basis and get their feedback (making changes to the DEV form and pushing it back over to UAT with a few changes) and then once you are happy with that, copy it over to Production for the rest of your users. 

The other way I have seen it, but more predominantly with Construction companies, is to split up the forms based on who is filling them out. For example, in a lot of cases you've got a Foreperson and a Superintendent who will need to be filling out different forms. In that case, I would have a Foreperson formspace and a Superintendent formspace (With an equivalent DEV and TEST formspace).

Geographical locations do come into play also as they might be using different data sources for the forms of different regions, but this could also be accomplished using Data Partitioning in the same formspace. 

To summarize, I would say that the most basic requirements would go with a Prod/UAT/Dev set up, adding more as the requirements grow; whether its language, region or even hair colour. 

Hope this helps!

Thank you 

------------------------------
Ian Chamberlain
Implementation Specialist
ProntoForms
------------------------------

Hi Stu. Good question here. We might be an odd case in that we have multiple subsidiary companies sharing the same ProntoForms environment, so using FormSpaces effectively has been really important to ensure each of our companies can keep their forms separated, but still cooperate on things when it is convenient.

We use a naming convention to make sure that FormSpaces remain orderly and easy enough to navigate for both our citizen-developers and our end users in the field. Loosely it is as follows: <Company Name> - <FormSpace Purpose>. Some companies simply need a development and a production environment, which we typically indicate with "Dev" and "Prod". Our more robust users of the platform will have dedicated FormSpaces for different groups of people. Safety, HR and Supervisor/Superintendent FormSpaces are the most common examples.

Similar to Lisa over at GOJO, the most specific we get is to create an individual FormSpace for a specific customer/contract/job. The value there was traditionally more focused on limiting how many forms users had to navigate. Now that we are getting better at using the form tags capability, we are finding that there is far less need to create additional FormSpaces for the same type of employees working on different contracts.



------------------------------
Matt Lambert
Vice President of Operations
PrimeLine Utility Services
mlambert@primelineus.com
------------------------------

I use one for development and one specific to our North America Field Service.  The reason we did so is we have had some interest in some of our international offices using ProntoForms.  Although I expect them to eventually have their own accounts and Pronto and then move our forms into their account, as our Canada division did.  The forms we have developed are designed to be used for multiple customers.  We don't have the diversity in forms that some of ya'll have developed.

------------------------------
Scott Gilleland
Senior Field Service Engineer
Messer Cutting Systems
------------------------------

@Ian Chamberlain @Lisa Zido @Matt Lambert @Scott Gilleland Thank you all for your contributions.

It's great to see so many practical variations on this and I'm seeing at least one consistency.

I love these examples!  Keep them coming folks, I'd love to hear from others as well!​​​​

PS: Once this comes to rest, I'll create a summary of options everyone can benefit from going forward.

------------------------------
Stu Rathbone
Program Manager ~ Knowledge, Training & Enablement
ProntoForms
community@prontoforms.com
------------------------------

Original Message:
Sent: 03-29-2022 07:58
From: Scott Gilleland
Subject: FormSpace Structure/Naming

I use one for development and one specific to our North America Field Service.  The reason we did so is we have had some interest in some of our international offices using ProntoForms.  Although I expect them to eventually have their own accounts and Pronto and then move our forms into their account, as our Canada division did.  The forms we have developed are designed to be used for multiple customers.  We don't have the diversity in forms that some of ya'll have developed.

------------------------------
Scott Gilleland
Senior Field Service Engineer
Messer Cutting Systems
------------------------------

We have a relatively simple system.

For our US operation, we have two formspaces:
1) Sandbox (for development)
2) Production (For final forms)

We utilize the same approach for our Mexico/Latin America operation, using Spanish versions of the forms in two similar formspaces.

Simple, but works for us.

------------------------------
Brian Dowler
Vice President, Customer Care
Conair Group
------------------------------

Most of our projects have two FormSpaces: DEV [Project Name] and PROD [Project Name] where we are able to review changes and test destinations/integrations and then deploy to the field respectively.
For some of our larger or more involved projects, I have found it very help to create a third FormSpace - DEMO [Project Name].
In this space I typically have a copy of the form (either what is in production or the most recent DEV version) that is not connected to any destinations (unless necessary for a workflow) and has no required questions. The form(s) in this space are used exclusively for demonstrations and training where we want to be able to run through the process quickly and repeatedly without having to fill it out in its entirety, or triggering any destinations. This is particularly helpful for workflows that involve multiple forms in which case I have the dispatches routed to the same user who submitted the form so they can easily demonstrate the process end-to end.

Best,
CC

------------------------------
Cecily Stelly
Analyst
Johnson Controls
------------------------------

Summary: Here are the key takeaways/best practices I took from the many great responses received on this thread.

It is apparent that you all have structured your FormSpaces in …. pretty much any which way you require ranging from the most basic, to complex.
(Shout out to our engineering team for building this framework to be as flexible as it is!)

1) Planning and foresight in the structure/naming of your FormSpaces is key.

          Goal: Keep the number of forms on your front line workers devices to the minimum they need to do their job.

2) Have one or more Development FormSpaces (depending on your structure) makes separating the development and testing of Forms easier to manage.
3) If your organization has time-bound contracts, create temporary FormSpaces for that purpose.
4) If your organization has Forms for different languages, having them in separate FormSpaces keeps your field workers inbox to just the Forms they'll use.

Bonus idea from @Cecily Stelly: 

Often we need to demo our great forms and it's features to others.

Create a copy of the form in a 'demo' FormSpace, remove any 'Required' options on all questions and remove the destinations from the Form. (Unless it is what you are showing off). That way you can quickly run through your form (without having to fill out all the required fields) and submit it without skewing stats, flooding email inboxes or sending test data to destinations.

Thank you to all of you who contributed, you have saved time for many who will follow in your footsteps by sharing your experience.

Do you have another best practice on Form Building, Administration, Integration, Analytics or Workflow design you would like to hear how others are approaching?
Ask away!!! (please start another thread to keep these separate)

​

------------------------------
Stu Rathbone
Program Manager ~ Knowledge, Training & Enablement
ProntoForms
community@prontoforms.com
------------------------------