Quite often we're asked for assistance with copying a process from one database to another. This is a common request for new customers who wish to move a process from a test database to their live database. The steps required to carry this out are detailed below.

Identify existing process to be copied

To begin with, identify the process you want to copy across so that the script it uses can be found and copied across to your other database. To do this navigate to the process you want to copy by going to Start > Configuration > Automation > Processes > Select the Process.

To get a copy of the script click on the script icon (shown above) > Copy the content of the 'source code' field and navigate to the database you want to set the process up in.
Within this database go to Start > Configuration > Automation > Scripts > New Script > Paste the source code into the 'source code' field > Give the process a name > Hit 'Save'.

Next, parameters for the script need to be setup. A parameter is a variable defined within the user interface, which the script will use. This allows the script to use different values without having to modify the script itself. At this stage we are simply saying what the parameters are and not assigning a value to them (this will be done at a later stage).

To do this go back to the script in your existing database > Select the 'Parameters' tab and view the full set of parameters (if there aren't any you can skip this step). If there are parameters, in your new database navigate to the parameters tab and create a matching parameter for each of the existing ones. Once you've done this, save and close the Script.

NOTE: It is important that the names of these are exactly the same for the script to correctly process them.

Setting up the new Process

Once you've copied the script across to your new database with any parameters, you can now create the Process. If you are unsure the difference between a script and a process, take a look here.
To do this go to Start > Configuration > Automation > Processes > Select 'New Process'. Give the process a name, select a script for it to use (the script you've just created) and set the schedule for it to run.

Next the parameter values for the process need to be set. This is done on the Process and not the script itself because it's possible that one script might be used for several processes and have different parameter values.

Quite often the parameter values can be copied across from one database to another, but there are some parameter values which are likely to be different on each database. It is recommended that for the following types of parameter values you check the value on the new database:

• Custom Fields - If a parameter references a custom field, it's possible that the custom field has a different field name on the new database (different to the field label which a user will see). It's best to check this. To do this navigate to Configuration > Select the record type for which the field belongs > Go to 'Custom Fields' > Add the 'Field Name' column > This will give you the field name of the custom field within a particular database.

• Templates - If a parameter is asking for a Template name it's important to check the template exists within the new database.

• Picklist IDs - If a parameter is referencing a picklist ID these might be different per database. You can find out the ID of a picklist by going to Start > Configuration > Customisation > Picklists > Add a column for 'ID'. This can then be used as the parameter value.

• Report IDs - Similar to Picklist IDs, report IDs may be different per database.

Once you've done this 'Save' the process to ensure the parameter values you've entered aren't lost.

Process Ownership

All processes run in the name of whichever User 'owns' it, therefore each process must have an Owner. Clicking on the padlock will show the current Owner of the process and the access permissions:

In order for the process to run, the Owner must be an enabled User with a valid Workbooks licence. We recommend that separate 'API Integration' user is created and used so that any actions/changes the process makes are clear to see from an Audit point of view (they'll appear as being made by 'API Integration').

If you don't wish to allocate a licence to an 'API Integration' user, please make sure the user the process is running as has full system admin rights and is exempt from password expiry. Failure to exempt the user from password expiry will result in the process falling over when the user is due to change their password, as like the user its password will be invalid.

One of the most common causes of process failure is due to Ownership. If you think your process has failed because of an issue with the Owner then please take a look at the section on Process Ownership found here.

Notification of process failure

On the main tab of the process, under the 'Other Settings' section, you can set which User is notified when the process fails and becomes disabled (we would advise that this is set to one of your Support Contacts so they can raise a Support Case if required. Bear in mind the potential impact of that user being on holiday or even leaving the organisation). If the process does fail for any reason, this User will receive an email notification that the script has failed and has been automatically disabled.