Concepts:
sfPMS uses special ATC commands within workflow scripts as a means to tell the system to do specific things at specific times. By creating ATC workflow scripts, you can set up automatic workflow to run at specific times, for a specific document, or for certain documents that use predefined routes.
Workflow refers to the set of relationships between all the activities in a project, from start to finish. These activities are tracked by various Doc types, some of which trigger new activities during the course of their routing or when they are saved or their status changes to Pending, Approved or Closed.
Automatic workflows can include simple scripts to alter the workflow and even create new documents. For example, you might want a Project Setup document to use automatic workflow to create one or more Punchlist documents, each routed to the correct person. Or you might want your Pay Request document to create next month’s Pay Request with instructions not to send it to the appropriate person until three or four days before it is due.
Automatic workflows are started in one of three ways:
- When a document condition triggers a workflow script according to a event established in the Workflow Script tool;
- When a Spitfire document is routed to a special built-in user called Spitfire. The basic concept is that you can route something to “Spitfire” and set a due date. When that due date is reached, “Spitfire” will run a workflow script (if any are available) and will send the document to the next sequence in the route. You can even use “Spitfire” as the routee more than once in a route. Since these workflow scripts are run by “Spitfire” they run at a higher privilege level than the typical user. Important Note: In part because of the elevated privilege level, avoid using workflow embedded in a route “to Spitfire” to change the document status to special statuses that require validation (such as committed or approved). These workflows are triggered AFTER the user has sent the document on and any failure will not return the document to the user.
- When a button in the browser is bound to a click event handler that calls sfRunWorkflowScript() with the name of a script in the workflow script library.
Permissions:
We recommend that most, if not all, workflow scripts be created and managed through the Workflow Scripts tool, found on the System Admin Dashboard. You must have the SYS | Global Access role capability or the PAGE | System Admin Dashboard and PART | Maintain Workflow Script Library role capabilities to access this tool. In order to create the actual workflow scripts, whether on the Workflow Scripts tool, the Routes tool (on the Manage Dashboard) or a document’s route, you must have the DOC | Can edit workflow role capability. [See the Designing User Roles technical white paper.]
With the exception of scripts run by a route to “Spitfire”, workflow scripts run within the security context of the current user and are subject to the user’s permissions. The logic in the script can do things a user cannot, such as set a status code that is not displayed, but user permissions still apply.
Related KBAs:
- KBA-01759: Validation and Document Logic Overview
- KBA-01777: The Workflow Scripts Tool
- KBA-01778: How to Create a New ATC Workflow Script
- KBA-01779: How to Associate an Event with a Workflow Script
- KBA-01780: How to Create Workflow on a Document
- KBA-01781: How to Create Workflow in a Predefined Route
- KBA-01782: The Index of ATC Commands
- KBA-01783: ATC Script Command Conditions
- KBA-01784: Examples of ATC Workflow Scripts
Last updated: September 1, 2020 at 22:13 pm