A business process will often have many steps. In Workbooks you will implement a series of small 'Processes' each of which combines to implement a full end-to-end solution. Keeping the steps small makes things much more maintainable.
The Scheduler within Workbooks allows you to define how frequently each different Process should be run, this can vary from every few minutes to monthly and be restricted to certain hours of the day or days of the week. For example you might schedule a process to check an external email server for new emails and import these into Workbooks to create new Cases: the 'Email to Case' script within the Script Library can be used to do exactly this.
You can use the 'Run Now' button to initiate a Scheduled Process at the next possible opportunity. To avoid complication, Workbooks restricts you to running only one Scheduled Process at a time; any others which would otherwise run at the same time are queued until the first one finishes. Workbooks will not run a Scheduled Process any more frequently than the schedule but will attempt to keep close to the requested schedule.
If a script fails in Workbooks, this can often be bad for your business if a process that normally happens in the background stops functioning and your System Administrator is unavailable to rectify the issue. To try and mitigate this problem, you can set a flag on a Scheduled Process to minimise any issues. There are two options:
- Run again – A script can fail unexpectedly for a number of reasons. Sometimes you can simply run the script again and everything will operate normally. This option is designed to handle an automatic re-run of a script and will come into play if the exit code is anything other than a 0, 1 or 2.
- Disabled automatically – If a script fails e.g. returns an exit code of 2, then it will become disabled until a System Administrator re-enables the process again manually. You can set who is notified on the event of a failure by changing the “Notify User” picklist.
Make sure that this is a 'real' user with a 'real' email address, otherwise a process might fail and no-one is informed so users presume the process is running as normal.
Alternatively, a Process Button can be added to your records, which, when clicked, initiates a specified Process. For example, you might add a button to a Case record that when pressed closes the Case and automatically sends an email to the Primary Contact using a relevant email template. You can also add a Process on Save, in which a Process is run everytime the Record is saved. A simple example demonstrates how you might implement a Process Button to delete all line items from an Order.
Process on a Report
It is possible to perform a Bulk Action on a Report by running a Process Engine Script. This allows the automation of common tasks on a group of Records, or extract and process data retrieved from a Report. This can be run on an existing or new Report.
To enable a process to be invoked from a report, open the relevant Report in edit mode and open the Automation tab. Click Add Process, give the process a name and select the Script that you want to run.
Once you've set up your process you'll see the Bulk Actions button on the Report. Selecting this will enable you to invoke the process.similar to a User-Invoked Process).
An example of this might be create a script which creates Invoices for selected Orders. You could then create a Report which shows these Orders, add the Process to the Report and then run the Process.
Running a Process
When a Process is run it is permitted to continue until it uses too much time, memory, or processor time. Set the Maximum Runtime for the process when you create it to something sensible: if a scheduled process loops continuously and doesn't finish no other scheduled process will start until it stops; a process button could appear to "hang" if the underlying process does not complete in a timely manner.