Duplicate forms

Hello everyone,

We are currently working on few ideas related to forms duplication feature in both single site and multisite. The idea is that we want to enable users to duplicate a form in the same site or in another site in the same instance.

 It would be great if you can answer my questions below: 

1) What is your particular scenario related to duplicating forms?
2) What do you expect to be duplicated: form fields, form layout, form responses or all of them? Why?
3) Do you want to be able to share a form between sites in order to use one and the same form in different sites or you just need to copy the form in order to reuse some of the fields and the layout?
4) If you have one form shared between sites how do you expect to see the form responses? Do you expect to see them per site?

Any other ideas are welcome!

Regards,
Antoaneta

1) For us...evaluations.  We have like 9 or so subspecalities, each want their own "version" of something.  The huge time consuming thing right now with forms is setting the developer name, making sure that's correct.  We pull the data from the tables into telerik reporting, so the default developer names Suuuuuuuuuuuuck (should be based on the title not the control type, like a page url).  So with lets say 15 controls on a page, new forms based on the first are annoying\cumbersome.  If you could tweak that functionality as well if you're onto forms...awesome.
Scenario 2: Complex javascriptery.  You guys don't have "Paged" forms yet, but we've implemented them with layout controls and some javascript to "page".  Like above, lots of little parts can get missed.

2) Not responses, just trying to save time building the thing

3) You don't mean multi-site here right?  You mean like if I'm making 2 sites and creating like "Contact" forms?....I can just do this by hand, I can't see sharing complex custom stuff between two projects, I'll defer this to the multi-site guys though.

Other:
- See above, fix the generated dev names :)  While SF exports with the names to excel, the db columns are still the gimpy controlname versions...impossible to know what matches what.

Dear Antoaneta

I would prefer a copy to copy everything. Its always easier to remove stuff then add stuff.

No multisite project - so I can not give any feedback on that.

Markus

We have uses for single and multi-site installs.

1. We have had a need to setup forms similar to each other with some minor additions or removal of fields. As Steve mentioned, we may have these unique forms that still carry over a large amount of fields from another form.
   
2. Duplicated items that seem standard would be the fields and layout elements. The responses should be unique to the form. We just need a way to make the tweaks to an existing form in order to have a new form and not have to rebuild the whole thing.
3. I would be great to duplicate a form from one site to another and be able to adjust it, while also being able to share a form as it is on other sites. We may want a standard form for capturing data that is used on multiple sites. If the same form was shared, the message or redirect url would need to be set per site. Obviously we couldn't have one form submitted on another site, redirect to the original site's page when submitted. We have added an ability to override the default setting when we add the form to a page. So if the form was set to redirect, we can change the url when it is added to a page in order to have a little more control over where the end user goes after completing the form. This was a way to share the same form within the same site and just change final page the end user will see. Think of landing pages with forms on them. You can have the same form on multiple landing pages, but the page they are redirected to would need to stay in the same section in which the landing page was created for. 
4. Overall, each site needs to see their own responses and have the ability to just export their own responses. Getting the data in should be shared, but the actual data needs to be separate.

I tend to agree with everyone here.

Primarily, it is about copying the entire structure so you have a nice base to work from, then tweak it accordingly.

Copying the response data would be a nice option, but really not necessary.

In a multi-site environment, the same holds true. We have many similar forms across a suite of sites, but they all need to be modified slightly.

For shared forms across sites, we would expect to see all the data in one place (same data visible and the form is visible across sites), but the ability to filter based on site. When exporting, the site should be listed in the data so it can be filtered post-export.

We have many custom controls in out forms toolbox. These need to come across properly when copied.

Hello everyone, 

Thank you very much for the input and the ideas. We will be working on the feature and will get back to you with some more information on the progress in the next days.

Regards,
Antoaneta

This is great. I was waiting on some feedback from one of our clients who really is looking for this.  I did use the work around code posted somewhere and that worked however it caused problems when she went to duplicate an actual form field on the duplicated form. It caused multiple controls with the same ID.
In any event, I think that for us - Richard Baugh said it best in his response 1 and 2.  We don't have any multisites so I can't answer to that.
Thank you.

Here is my response.

1) What is your particular scenario related to duplicating forms?

We run promotions for our customers/dealers and in order for them to redeem for a promotion they need to fill out a redemption form which is just a Sitefinity form.  For each of these promotions we need a new form, so it would be nice if we could duplicate an existing Sitefinity form and start modifying from there.

On top of that we sometimes create branded landing pages that could live on any one of our web sites.  All of our sites exist in the multi-site module so it would be nice if I could share the form and form responses across different sites but still maintain the form in the original location where it was created.

 2) What do you expect to be duplicated: form fields, form layout, form responses or all of them? Why?

I would expect form fields (and all controls in general) and form layout to be duplicated.  I would not expect the form responses to be duplicated since you are technically creating a new form, but maybe it would be nice to have an additional option asking if you want to copy the form responses as well.

Also, I want to note that controls should also be copied.  For example, I have setup our forms to add the JavaScript page widget on our forms.  This allows us to add custom JavaScript to the forms so that we can get around some of the limitations with the forms module such as showing and hiding fields based on conditions,

 3) Do you want to be able to share a form between sites in order to use one and the same form in different sites or you just need to copy the form in order to reuse some of the fields and the layout?

If I share a form across different sites then I would expect the form to be the same and NOT just a copy of the form.  Although it would be nice if I could duplicate (copy) a form to a different site.  So the key here is SHARED versus COPY.  SHARED implies the same form just available on another site and COPY implies the form was duplicated to create another instance of the form.  I feel a good solution would deal with both scenarios.

 4) If you have one form shared between sites how do you expect to see the form responses? Do you expect to see them per site?

I would say that it is the same form whether it is on site A or site B.  In the same token I would expect to see all form responses whether they were submitted to site A or site B as the same since they where submitted via the same form.  My expectations would not be that since I shared the form (same form instance) to another site that it would have a different result set, because again it is the same form.

If you wanted to see a separate set of form results then I would say you should duplicate (Copy) the form to the other site.

OTHER NOTES

I also want to mention two other items that, in my opinion, would make the Sitefinity forms solution much more powerful and provide huge value to your customers.  This includes...

First, the ability to create paged forms, such as a wizard style form.  I know there is a work around for this in JavaScript but I think it is high time to get this functionality baked into the product.

Second, the ability to apply conditional logic to forms which would cause form fields to show or hide.  For example, if I check a checkbox field it would cause a textbox field to display. 

Hopefully this has been helpful.  Thanks.

Craig

We've got a stage instance and a production instance on Azure.  Whenever we have a large go-live where individually syncing pages from stage to Prod proves to be too time consuming, we do a copy of production's database appending _DATE_BACKUP, then a copy of stage's database, and rename the stage copy the Production databases' name.  This way we don't have to do a full publish from Visual Studio to Azure, tearing down and building back up servers, losing cache, the painfully slow initial first start-up of the servers.  Because of this, all form responses in the backup of production get lost.  We can still get to them to export the form results by wiring up another Sitefinity instance to look at the back-up, but that stinks.

Ideally, I'd love it if any form submission from Production could be synced to Stage so the results are the same in both databases.  I looked into doing this through Azure's new Sync feature, which lets you decide a source and target server and sync specific tables or just specific columns, but Sitefinity's database is a bit on the complex side and I couldn't sync just the forms without also syncing things in some object table, which we don't want.

Also, since there is currently no form syncing functionality (we're on 6.1.4600), any form we build in stage has to also be built in production.  And if we sync a page from stage to production that has the stage form on it, we have to log into production, delete the form, and re-add the production version.  It's a pain and a LOT of the reason the marketing departments at my company have A) asked for me to write custom forms that just simply email a person or distribution list the results or B) have gone the route of services like Pardot, where the marketing dept can build the form, provide me iFrame code for my Sitefinity pages, and then they control everything, bypassing Sitefinity completely (other than to display their Pardot form).

While I'm on my soapbox, unrelated and I apologize in advance, the sfref stuff is killing me.  Since we switched to the Multi Site License, I've been tasked with duplicating sites currently in group folders off the main site's root into their own "site".  After finally getting code that worked to duplicate the pages between sites, every link is broken because Sitefinity adds the sfref attribute to the links and those IDs for the linked pages don't exist (?) in the new site and every...stinking...link has to be modified to remove the sfref attribute.

1. Usually, just need to duplicate forms because most of the fields are same, maybe one or two field changes. So it would be easier to duplicate a form and make some changes than recreate the whole thing.
   Also as Steve said in the first reply, it would be good to have developer names based on Title rather than control type, or atleast to have some sort of concatenation of title and control type, so that if we build a custom control for the form, then we can lookup fields based on title.
2. Just form fields and layout should suffice along with any configuration like thank you message or redirection etc. Each form would have their own responses so we don't think duplicating the responses is necessary.
3. So far, we haven't needed to share a form between sites. But we have had a situation where a new form has to be added to an already live site. In this case, we usually create the form locally to test some custom functionality and then once everything works, we have to recreate the form on the live site. So some sort of export/import of the entire form would be a nice add on. This would also be handy to copy over similar forms between different websites.
4. If the form is shared between two sites, we would expect all the responses to show up in both sites with some column showing the public page url where the form is or some sort of obvious distinction to know where the form was submitted from.

Hello everyone,

We are also working with the multisite solution and I think Craig described exactly our needs. I couldn't have phrased this better.

Regards,
Chris

I also agree with everything Craig said. I think everyone else has already provided the same feedback we would. Look forward to this time-saver.

Thanks!

Hello everyone,

Thank you all so much for your responses, feedback and suggestions. 

This is to update you on what we are planning to work on:

1) Ability to duplicate forms - all widgets and their settings, layout elements and content will be duplicated, except form responses and subscribers. 
2) Ability to share forms created in one site to another one in the same instance. In the form responses screen you will have the ability to see from which site every single response is coming
with a filter per site. 
3) Ability to add specific URL used for the Thank you page per form using a setting in the Forms widget (for shared forms in multisite). 

When you duplicate a form you will need to go through its create screen first to enter the new form title. By deafult we will add _Copy next to the old form title but please note that the name for developers will be  the same as the form you copy from and you will need to edit it on the go. We are still trying to find a better way to control this name as it cannot be changed later. 

Any feedback, comments and ideas are welcome.

Regards,
Antoaneta

@Antoaneta
  - Not gonna touch the developer name generation at all?
  - Whats the specific Url for?...is that like the canonical url\location for that form?

Hello Steve, 

1) Developer name: Unfortunately we are not able to make any major changes related to the developer name at this moment
2) The URL is for the Thank you page that you want to redirect the users to

Regards,
Antoaneta

@Antoaneta

Will this be part of the Sitefinity 7.0 release?

Craig

Hello Craig,

Yes, we are aiming to introduce the above mentioned improvements with the 7.0 release.

Regards,
Antoaneta

This just came up here...

Okay with 6.2 the forms developername of "Username" is *NOW* a reserved word.  So all our forms that have the Developername of "Username" are borked and the forms need to be re-created.

This forms duplication functionality would be awesome if on duplication it worked liked duplicate page does.  So I duplicate the form then it drops me into edit mode so I can change all the developer names BEFORE it gets saved to the DB (as you can't change the metafields after the fact).

Yes, no?

Hi Steve, 

Thank you for pointing this. Currently when you duplicate a form the duplicated one is created as a Draft and if you go to edit its content you will be able to change the developer name in all the controls. Please note, that after the form is published that will not be possible.

Anyway, we plan to add the ability to edit the form during the process of duplication (like it is now in Pages).

Regards,
Antoaneta

Hello everyone,

 Have you had the chance to review the Forms duplication and Form sharing features that are included in our recent Sitefinity 7.0 BETA release? 

We are looking forward to your feedback and suggestions! 

Regards,
Antoaneta 

Related: 
...I tried to break it, but it seems solid, thanks much! :) (Attached)

Not Related:
- If I edit a developer name on a form widget, and blur (click off the field) nothing shows in the UI, just an empty area where the change should be and the "change" button.

Hi Steve,

Happy to hear that:) 

We will check the issue you described and it will be fiixed.

Regards,

Antoaneta