How to duplicate records between accounts for review using script

Purpose of the script

This script is designed to duplicate records between accounts in order to fulfill a scenario whereby those records need to be shared between three parties, as seen below:

  1. A master account who owns a form and stores its records – we’ll refer to this account as DemoMaster
  2. An internal staff account that needs access to the records stored by DemoMaster – we’ll refer to this account as DemoStaff
  3. And a user account who owns a duplicate of the record they’ve created – we’ll refer to this account as DemoUser
Implementing the script

On DemoMaster’s account, we need to create our primary form, either single or multi-form, and build the script into it that will provide the functionality as described above.

For this example, we’ve created the simple form seen below, which captures a value and the user’s email address, which you can view here.

Duplicate Record and Review Demo Form

We’ll break the script down into three parts – let’s take a look at part one:

$('#footer-btns').children('.btn-submit').remove();

$('#footer-btns').append('<a id="btn-finalise" class="btn btn-success btn-save btn-submit2" style="display:none; text-decoration: none; margin-left:.5em" onclick="DuplicateDocumentOnSubmit();" href="#">Submit</a>');

function DuplicateDocumentOnSubmit(){

In the script above, line 1 removed the default submit button and line 3 creates a replacement submit button that calls the custom function, seen starting on line 5.

The code below is the second part of the script, which is inside the custom function seen starting above. This part of the script controls how the form is saved into the master accounts records:

    fld('UserCanSaveDoc').val('false');
 
    fld('zf_SavetoFormOwner').val('true');

    $('#DocumentEmailRecipients').val('david.harrison@zumesoft.com');     

    $('#DocumentTemplateURL').val('https://create.zumeforms.com/Users/Demo/templates/Testing - Lawyer.docx'); 

    $("#isFormSubmiting").val("false"); 

    $('#zf_AllowWord').val("true");
            
    $('#zf_AllowPdf').val("true");                    

    FormSubmitStart();

Let’s break this script down a little:

  • Line 7 is a setting that controls whether or not a dialogue is presented to the user to allow them to download a copy of the generated document. For the portion of the script above, we want this set to false.
  • Line 9 is a setting that controls if a record is to be saved to the form owners account. For the portion of the script above, we want this set to true.
  • Line 11 controls who the form will be emailed too. If you remove this line, no email will be sent.
  • Line 13 controls what document template will be used for the document generation.
  • Line 15 is a setting that controls whether or not an after assembly workflow runs. For the portion of the script above, because we still have the user assembly to run, set this to false.
  • Line 17 is a setting that determines if a word document will be generated.
  • Line 19 is a setting that determines if a pdf document will be generated.
  • Finally, line 21 starts the document generation and saving process.

The third part of the script controls how the form is saved in the user account’s records:

    fld('UserCanSaveDoc').val('true');
     
    fld('zf_SavetoFormOwner').val('false');
 
    $('#DocumentEmailRecipients').val('{{Client_Email_eml}}');
            
    $("#isFormSubmiting").val("true"); 

    $('#zf_AllowWord').val("false");

    $('#zf_AllowPdf').val("true");

    $('#DocumentTemplateURL').val('https://create.zumeforms.com/Users/Demo/templates/Testing - User.docx');
            
    FormSubmitStart();

}

Again, let’s break the script down:

  • Line 23 as before, controls if the user is present with a download dialogue.
  • Line 25 as before, controls if the record is saved to the form owner’s account – because this has already been done in the second part of the script, we want this set to false.
  • As before, line 27controls who the form will be emailed too. The difference here is that the script is getting the email address from a form field.
    In the example script above, the email field is called “Client_Email_eml” – replace this with the name of the email field in your form.
    If you remove this line, no email will be sent.
  •  As before, line 29 controls if an after assembly workflow can run – set this to true.
  • Line 31 and 33 control the document generation types, as above.
  • Line 35 select document template to use in the assembly.
  • And finally, line 37 starts the document generation and saving process.
Optional Extras:

In addition to the script configurations explained above, there are a few optional settings that can be enabled:

Allow an end-user to select the record save location

fld('zf_customsavefolder').val('true');

Adding this line to the third part of the script (saving to user record) after fld(‘zf_SavetoFormOwner’).val(‘false’); will popup an additional dialogue to the user, allowing them to select where they want their record saved.

Automatically set logged in users email

As an alternative to the client email collection outlined above, we can instead automatically collect the email address of the logged in user filling out the form.

To do this, you need to add a hidden field into your form, with a field name of “MyUserDataEmail”. Then in the second half of the script (saving to user record) change the DocumentEmailRecipients setting to feature this new field name, like this:

$('#DocumentEmailRecipients').val('{{MyUserDataEmail}}');

Controlling Output Types

For this final extra, we can configure the script to behave slightly differently, depending on who is filling out the form. In our example workflow, there are two different users who might fill out the form:

  • DemoUser
  • DemoStaff

DemoUser should only receive a pdf document, but if DemoStaff uses the form, we want them to receive both a word document and a pdf document.

So how do we do this? Well, this relies on one condition being met – the first is that DemoStaff needs to have the same email domain on the addresses that their ZumeForms accounts were created with i.e. Persona@DemoStaff.com.

Provided they have the same email domains, create a hidden “MyUserDataEmail” field on your form, then in the second half of the script (saving to user record) change the code that controls document format from this:

$('#zf_AllowWord').val("false");
            
$('#zf_AllowPdf').val("true");

To this:

$UserAddress = fld('MyUserDataEmail').val();

if($UserAddress.indexOf("@demostaff.com") >= 0){
    $('#zf_AllowWord').val("true"); 
} else {
    $('#zf_AllowWord').val("false");
}

Make sure you change the email address ending in the contains to the email of your internal staff.

Finishing Off:

Once you’ve built your form and configured the script as desired, there are three final steps:

  1. Create a records folder under Your Records where your form’s records will be kept.
  2. Hover your mouse over the newly created folder and you will see a permissions link. Click the link and a permissions dialogue will appear.
    This is where we can specify access permissions for the internal staff accounts, by entering the account name into the text box.
    Add an access permission for each staff account that needs to access the records.
    permissions
  3. When you save the form, select the newly created folder as the save location, as seen below, in our example a folder titled “Duplicate Record and Review”:
    permissions2