States and Escalation
State Block
State blocks are the most common block for a workflow, allowing further data capture after the Start state is completed.
States share several properties with the Start state, with the addition of Observers. You can name these states appropriately, keeping in mind that, by default, state names may appear for end users in their task list. Unlike Start, normal states may be deleted if necessary.
| Property | Description |
|---|---|
| Name | By default, Start is named '(Start)' and each new state added is named 'State #' with an incrementing number. The name can be changed at any time, however each state name must be unique. |
| Allow Cancellation | Gives the option to cancel the workflow immediately. When enabled select any of the following user types who can cancel at this state: By Current Assignee – The person currently assigned to the workflow. This user can click the Cancel button from the Home page or a Dashboard. By Creator – Whoever initiated this workflow in the Start state. By Previous Assignee – The person who submitted the previous state of the workflow to the current assignee. |
| Due Date | Due Date can be used in a Dashboard to highlight past due tasks. Escalations will run on their own trigger. Available options are: None – No Due Date Days After – Number of days after the workflow reaches this particular state. Optionally, the Designer can select only Weekdays. Date – Specific date using a reference question in the form (Calculated via Formula or Date Questions type). |
| Mentions | Gives the option to engage additional users or invite them to a workflow by mentioning them in a comment using the ‘@’ syntax. Any user mentioned will receive an email notification with a link to the state or comment. Users with State Access – Only users that currently have access to the state can be mentioned (default). Anyone – Any user can be mentioned and they will be dynamically added as an observer to view the task and make comments. |
| Observers | (Not applicable on Start state) Configure a user or group to view a read-only version of an in-progress workflow as well as specify the communication template to use. |
Escalations
Escalations perform tasks, like reassign and send email, when triggered based on configurable conditions. State blocks with escalations show the escalation icon in the top right. Click the icon to open the 'Escalations' tab in the Inspector panel. Individual Escalations properties and inputs can be edited by clicking the 
icon.
Any conditions required to trigger the Submit Task action must be complete before Workflow Assignment occurs, during the creation of the Escalation
This means that any actions that need to input into those conditions must be run no later than "Run After Document Generation", "Run After Finish" will be too late.
Avoid using 'Current User' transitions when also using the Submit Task escalation
The Submit Task escalation submits the task as the configured Submit Task Manage Settings user, so a "Current User" workflow transition will result in a task assigned to the Connector Settings service user.
| Escalation | Description |
|---|---|
| Post to Webhook | With the Webhook action, you can call your own HTTP endpoint when a form is submitted and optionally include form answers. This means all your connector logic can remain in an external service that can be updated and load-balanced separately. The service call is made as a POST and the body of the request contains the JSON payload. This action does not deal with the generated documents. |
| Push Notification | Ability to send Push Notifications to the Offline App which has been registered to a user. If there is no user or group GUID specified, the notification will look at the current workflow state (if it is within a workflow) and send a push notification to the current user or group. |
| Reassignment | Allows reassigning current State to another User or Group. |
| Send Email | Sends an Email similarly to the Email Action with the difference that can be configured to be recurring using Escalation parameters. |
| Send to REST Service | Makes a request to a REST API every time the Escalation is triggered. |
| Submit Task | A submit step escalation will progress a workflow from it's current state to a destination state. The Submit Task Manage Settings user must be set else this escalation will fail. |
| Terminate Workflow | Terminates workflow when escalation Initiate condition is met. |
Escalation Inputs
| Post to Webhook | Description |
|---|---|
| Answer Values | Optional values and question references that you want to send to your service. |
| Secret Key | User-provided API key that is sent to and validated by your service, limited to 255 characters. |
| Webhook URL Endpoint | your service url |
| Escalation | Inputs |
|---|---|
| Push Notification | Group or User GUID - Send a push notification to every member of the group specified or to a user |
| Reassignment | group/user assign - the group or user to be assigned |
| Send Email | Reply to - Email address to where recipients will reply to the escalation email. Email addresses supplied to the Cc and Bcc inputs can be semicolon ; delimited. Note Only one email address can be entered into the 'Reply To' input. Multiple 'Reply To' addresses will cause the Send Email Escalation to fail. |
| Send to REST Service | For more information, refer to the Send to REST Service |
| Submit Task | Discard Saves - A true/false value for whether the escalation discards any save in progress answer files which may exist. For example, the user started the form and saved before finishing. set question value - This uses a question reference (ID and name) and attempts to update the questions answer value to another value. Target State List (name|name) - Accepts a pipe separated list of state names that the escalation will attempt to transition to. Used in conjunction with transition conditions, which is the recommended way of filtering transitions, to find a target state. Available transitions must resolve down to exactly 1 for a successful escalation transition. |
| Terminate Workflow |
Properties
| Property | Description |
|---|---|
| Interval | Allows to define when this Escalation should be triggered. Day/Time allows Question References to resolve a date and time. (Date: The recommended format should be standard date format, yyyy-MM-dd hh:mm:ss.s) (Time: Should be in local time because time will get converted in the system to UTC.) ASAP – Triggers the escalation task as soon as the task is added to the queue and the scheduler becomes available. |
| Weekdays only | Makes sure the escalation will only occur on a weekday |
| Retry on failure | Allows the user to specify the number of retries and time before the next retry. This may mean that it may not run at the exact delay specified, however it will never be shorter than that time period. |
| Reoccurrence | Some escalations allow for a recurrence schedule where you can define the pattern and range of occurrences. |
Updated about 2 months ago