SmartIQ workflows are comprised of workflow states flowing from one to another via transitions, completed sequentially, or in parallel, from start to finish.
A well made workflow streamlines business processes, allowing different users to collaborate at different phases or times. This automation uses business logic to help organisations perform consistent business processes and improve organisational efficiency.
The workflow interface shows the following:
- Diagram that provides a visual representation of the workflow
- Configurable properties for each state and transition
- Escalations and actions that can be added to the workflow
Each part of the interface is described in more detail below.
The Global Nav Bar for SmartIQ Design, providing key project-level functions like Save, as well as an easy toggle between Form and Workflow views. For more information, refer to Global Nav Bar.
Each item in this panel is either a block ready to drag and drop onto the canvas, or a collection block that can be clicked to reveal a pull-out menu of blocks that can be dragged onto the Workflow Canvas. The left panel includes the following:
States – A workflow state is a stage or step in the workflow process. For more information, refer to Workflow States.
Approval – An Approval is a step in a workflow that acts as a gateway, where the responses provided in the form thus far can be reviewed and, if appropriate, altered before progressing. For more information, refer to Approvals.
Event – An external step in a workflow that needs to be actioned by a system outside of the SmartIQ platform via Cloud-to-Cloud Integration (C2I).
Parallel – Parallel blocks create a sub-process that allows multiple workflow states to occur in parallel by assigning states to multiple users simultaneously. For more information, refer to Parallel Workflows.
Transition – A transition is the link between the end of one state and the beginning of another, creating forward (and backward) paths within a workflow. For more information, refer to Transitions.
Actions – Actions provide a way to execute additional functions, whether calling an external system's API, sending an email or many other tasks. Actions are associated with workflow transitions and are executed when the transition is run. For more information, refer to Actions - Overview.
Escalations – Escalations are similar to Actions, except they occur based on time lapsed in the target state. For example, an escalation can be used to send an email reminder that a workflow task is overdue. For more information, refer to Escalations.
The workflow canvas provides an interactive visual representation of the workflow, with states and connecting transition lines. States are placed on a grid providing an easy and neat way to lay out your workflow.
- Create workflows by dragging and dropping blocks from the left panel, and place in an available space in the grid. Once placed, states can easily be moved around the grid.
- Alternatively, states can be created by clicking an empty grid marker to reveal a pop-up menu.
- Create transitions by clicking on a state and dragging the transition to the next state.
- Clicking states or transitions from the workflow canvas opens the Inspector panel to enable editing that item.
- Transitions with actions show an action icon. Hover over the icon to reveal the number of actions, or click the icon to open the Actions tab in the Inspector.
- States with escalations show an escalation icon. As with the action icon, hover over to reveal the number of escalations, or click to open the Escalations tab in the Inspector panel.
- Editing parallel workflows drills into its own parallel workflow canvas, with a breadcrumb link to the parent workflow(s). Additional nested parallel sections follow this same pattern.
Use the View Options floating toolbar for more control over the workflow canvas in changing the display zoom and other view settings.
- Zoom Controls – Use + and - buttons to increase/decrease zoom or click the zoom % to reset to 100%
- Center View – Centers content and zooms to fit the area.
- View Settings:
- Circuit Layout – Show circuit style layout of transitions, where transition lines go around states instead of direct paths. Default setting is off.
- Selection Focus (muted/hidden) – When a state or transition is selected, anything directly connected to it will be clearly visible, while everything not directly connected will be muted or hidden depending on which option is selected. This enables focusing in on a smaller area of the workflow and would be especially helpful for complex workflows. Default setting is off.
- Markers – Show/hide empty state placeholder markers. When hidden, you can still hover the empty space to reveal the + context menu for adding a new state. Default is to show markers.
- Grid – Show/hide grid lines surrounding state placeholders. Default is to not show grid.
The Inspector Panel displays the available properties of the states and transitions in your workflow.
- The panel can be pinned to always show or unpinned (default) to only show when an item is selected.
- Click the More Options (three-dot) menu to Delete or Copy To (only for Transitions).
- The tabbed view displays the tabs or sub tabs with the count of relevant items.
Displays the general properties for whichever section in the form you have highlighted.
- Shows Outbound and Inbound transitions as lists.
- Click button to quickly Add a new outbound transition.
- Hovering a transition will highlight the transition in the workflow canvas.
- Buttons to quickly Copy To, Edit or Delete the transition.
- Delete All option to quickly delete all outbound transitions.
See Transitions for more information.
- Click button to quickly Add new escalations.
- Click the More Options (three-dot) menu to Duplicate or Copy To the escalation.
- Buttons to quickly Edit or Delete the escalation.
- Delete All option and confirm to quickly delete all escalations in one go.
See Escalations for more information.
Other things to consider in Workflow are:
Email Approval – which only work for workflow approval projects. For more information, refer to Email Approval.
Track Changes – This features shows the history of who made a change when it was their turn. For more information, refer to Track Changes.
States are indicated by blocks that are dragged onto the workflow grid, blocks are connected together to make a workflow by using transitions between them.
|Start and Finish|
|Actions||project actions but in workflow relate specifically to a transition|
Start is the initial state for all workflow projects, and, while it cannot be deleted, it may be renamed and otherwise behaves very similarly to a regular state. This is commonly used to initiate a process or request, capturing data from the requester.
Users who initiate a workflow form in this state are considered the workflow Creator.
Refer to State Properties for a list of properties in the Inspector for the Start state.
While not strictly a state, Finish represents the final termination of the workflow and is always present in a workflow. It has no properties and, as such, is not selectable in the canvas, and can only have inbound transitions. Once a workflow reaches this state, it cannot progress further and is therefore considered completed.
States are the most common building blocks for your 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.
|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. Default for Start is to not allow cancellation. When enabled select any of the following user types who can cancel at this state: |
|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: |
|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. For more information.
An Observer is a passive role that allows users to view a read-only version of an in-progress workflow. Observers can make comments where comments are enabled. However, observers cannot make changes nor submit a form.
The observer roles are applied to workflow states (including approvals), where different workflow states might have different observers appropriate to the business process. Observers can be combinations of particular users or user groups.
For a sample project that sets either a user or group as an observer, download this project. For a sample dashboard project that displays the resulting data from User Assigned and Group Observer Tasks, download this project.
Notifications can be sent to the stakeholders, which can be customized through communication templates. Which observer Communication Template to send is configured in either the Approval properties page in Manage or directly in the workflow properties in Design.
These notifications should provide a [ProjectLink] directly to the form that, when accessed, provides a read-only view of the form as well as an alert to indicate that this role does not allow changes.
Workflows for which the current user can observe do not appear in the SmartIQ home page. If a list of such workflows is required, create a Dashboard and use any of the following data objects:
- User Assigned and Group Observer Tasks
- User Assigned Observer Tasks
- User Group Observer Tasks
Gives the option to engage additional users or invite them to a workflow by mentioning them in a comment. This is done by typing ‘@’ within a comment area related to a question or on the Approval overview page. Autocomplete will provide a list of people that can be mentioned.
Use this feature for adding individual users into the workflow. To add groups, add the group in Design.
Additionally, temporary users will not be able to use this feature.
The following options are provided:
Users with State Access (Default) – This will be anyone already engaged in the task within the workflow. Mentioned users will receive a notification and can approve or make changes to the workflow.
Everyone – Any user in the system can be mentioned. Mentioning a user will dynamically add them as an observer to view the task and make comments.
Mentioned users will be part of the communication chain and will receive a notification that they have been mentioned as well as for comment replies within the thread.
Approvals are re-usable steps that perform the most common workflow patterns around reviewing and approving or rejecting workflows, and apply in a single step, simplifying what might otherwise be a complex structure to build and maintain.
When added to the workflow, the user can select an approval from the drop-down list of available approvals that have been configured in Manage Approvals.
|Name||By default, this is the selected Approval type, and, if duplicated, an incrementing number is appended. The name can be changed at any time, however each state name must be unique.|
|Approval||The name of the selected Approval.|
|Enable Quick Approval||Enabling this option gives the Approver the ability to quickly approve or reject the request from the Produce dashboard. See Quick Approval for more information.|
|View||Provides control over what view approvers will see when entering this form to review. Select from 'Form' or 'Summary' (default is Form) as follows: |
|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. |
|Approvers||Configure any approver user roles defined in the Approval in Manage, and map to named users either fixed or dynamic by reference. Add as many roles as needed to fulfill the requirements of the Approval. Note this property is only displayed when the Approval includes clauses of type 'User'.|
|Observers||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. For more information, refer to Observers.|
An external step in a workflow that needs to be actioned by a system outside of the SmartIQ platform via Cloud-to-Cloud Integration (C2I). Additionally, the workflow will only progress after the process has finished.
When a workflow lands on an event state, the request is sent to the cloud system by an action on the inbound transition. Usually, the action will be creating some sort of work item or ticket for which the system is responsible for processing. For example, the DocuSign Create Envelope action.
After the external process finishes, the cloud system notifies SmartIQ for the workflow to continue. Continuing the workflow may mean closing off the workflow or triggering more states and approvals. The outcome of the request, whether approved, denied, finished, or deleted, controls how/if the workflow moves forward.
Because External states are external cloud systems, they are not assigned specifically to any SmartIQ user or group and will not appear in lists or dialogs for “workflows assigned to me”. The progress can be checked in Form Activity or by workflow administrators in Manage > Workflow.
The DocuSign event allows data to be collected in a SmartIQ form/PDF document and sent to DocuSign for signatures.
The External State is the state wherein SmartIQ waits for the signature process to complete and DocuSign sends the result back to SmartIQ so the workflow can be continued or finalized. The process relies on Cloud to Cloud (C2I) integration between the two platforms.
The individual workflow states and components are configured on the SmartIQ Design workflow canvas. A basic DocuSign integration requires the following components:
- A Start state for collecting data to generate a PDF document.
- A DocuSign Create Envelope action that passes the generated PDF payload to DocuSign (automatically added when a transition is created to the external state).
- A DocuSign Event where the SmartIQ workflow will wait while the DocuSign Signature Process takes place and continue the workflow once the result is received from DocuSign.
Additionally, when a workflow transition is moving to a DocuSign External State, the Action responsible for creating the DocuSign Envelope will ensure that the “envelopeId” is coupled with the workflow and wait for the DocuSign response.
To set up SmartIQ and DocuSign C2I integration:
- Configure Manage settings in SmartIQ to be able to send the data to DocuSign.
- Create a DocuSign Service Account specifically for DocuSign.
- Set up DocuSign Connect to ensure that SmartIQ receives authenticated and validated messages.
Create a SmartIQ user account that will be used exclusively by DocuSign. Ensure that this account has the correct permissions to access forms adding it to the appropriate SmartIQ groups and that Impersonate Users permission is enabled to enable preparing forms on behalf other users.
- Go to Manage > Roles > New Role and create a new DocuSign role.
- Role Name: DocuSign
- Permission: Impersonate Users
- Click Save.
- Go to Manage > Users > New User and create a new DocuSign user. For example, Docusign Service User.
- Click Save.
- Click Security and select the relevant Groups to ensure the service account has access to all relevant forms and that the new docusign role is selected.
- Click Save.
Set up DocuSign Connect to send real-time updates to SmartIQ via webhooks with the following configuration:
|URL to Publish|
|Include Basic Authentication Header||DocuSign service account name and password|
- Drag and drop an Event state onto the workflow canvas.
- Select DocuSign from the External Event Type drop-down list.
- Click OK.
- Add a transition to the Event state. An action suitable for notifying the cloud system will automatically be added to any inbound transitions to the state.
- Configure the DocuSign actions to suit the workflow.
- Add the document to the Action Documents tab.
- (Optional) Add conditional outbound transition(s) based upon the result of the external event. For example, a workflow can proceed to the Finish state only when the external system triggers an “envelope-completed” event.
You can add conditional outbound transition(s) based on the result of the following external events:
|envelope-completed||The envelope has been completed by all the recipients.|
|envelope-declined||The envelope has been declined by one of the recipients.|
|envelope-voided||The envelope has been voided by the sender or has expired. The void reason indicates whether the envelope was manually voided or expired.|
|envelope-deleted||This event is sent after an already-sent envelope is deleted within the web application.|
|envelope-discard||Sent when an envelope in a created or draft state is deleted within the web application or discarded within the tagging UI.|
- Save your project.
The OneSpan External State Extension allows data to be collected in a SmartIQ form/PDF document and sent to OneSpan for signatures. Once the signature process is complete, OneSpan sends the result to SmartIQ so the workflow can be continued or finalized. The process relies on Cloud to Cloud (C2I) integration between the two platforms.
To receive the OneSpan response, SmartIQ exposes a WebHook specifically designed to receive authenticated and validated messages.
- In Manage, go to Settings > OneSpan.
- Specify a Callback Key. A relatively long string, similar to a guid.
- Save the Settings.
- Go to your OneSpan console and register for event notifications.
- Set the callback URL to your produce URL) + /webhooks/OneSpan. For example,
- Set the callback key to the same value that was entered in Manage settings.
- Select event notifications to send to SmartIQ.
Only the events listed will processed. Others will be logged (if debug mode is on) and ignored.
|PACKAGE_COMPLETE||Complete||A package has completed the signing process.|
If there are multiple signers then the "sessionUser": "...", will be the signer ID of the last signer to sign.
|PACKAGE_TRASH||Trash||A package was moved to the trash folder in OneSpan Sign's Inbox (status = TRASH).|
|PACKAGE_DELETE||Delete||A package has been deleted from the OneSpan Sign.com system.|
|PACKAGE_DECLINE||Decline||A recipient has declined to sign a package, and has specified a reason for doing so, The Originating System can use that reason to determine the next step for the package.|
|PACKAGE_EXPIRE||Expire||A package has exceeded its expiration date.|
|PACKAGE_OPT_OUT||Opt_Out||A recipient has opted out of signing a package.|
|PACKAGE_ARCHIVE||Archive||A callback notification indicates that a package has been archived.|
You can now add an External State Event to your workflow project and select the OneSpan state type.
This feature allows workflow states to be assigned to users simultaneously, and for the workflow to progress only once all concurrent states have been completed. Question references are resolved concurrently across all states in a parallel section. Parallel sections can optionally be exited from without requiring consensus between assignees, and tasks can be reassigned without affecting the other parallel tasks. However, termination of a parallel task will result in the termination of all tasks in the same parallel section.
Additionally, concurrent editing can be blocked to ensure that no submissions are overwritten.
Consider the following example for a workflow:
In this example, the flow of control is simple with single expectations at each state. Now consider the example below:
In this case, a “2-step authorization” process is involved. The issue with this is that if one of the authorizers is not available, the allocated task is held and can only be progressed by the actions of an administrator.
Parallel Workflows allow a part of the workflow to run concurrently. Using this approach, we can alter the process above as follows:
- Remove the
Authorize 2states from the main workflow.
- Add a Parallel section onto the canvas, then uncheck Block Concurrent Editing in the Inspector panel (see Block Concurrent Editing).
- Double-click the new parallel section on the canvas or click Edit Parallel Workflow in the Inspector to open it.
- Drag and drop two states into the parallel field, and name them
- Add a transition from
Processto each of the
- Finally, add a transition from both
Authorize 2states to
You will get the structure as shown below:
Now when this project is run in Produce, both Authorize states can be worked on immediately, in any order, when the Process state is completed - Authorize 2 is no longer waiting for Authorize 1 to be completed.
Once both Authorize states are completed, the workflow will progress to finish.
With parallel states, multiple end users may be accessing the workflow form at the same time. To prevent race conditions with potential data loss, parallel sections by default block concurrent editing.
With this option enabled, when the parallel states are assigned to their multiple assignees, the first one to open it will be able to proceed as normal and edit the form. Any other assignees, if they try to open their tasks while it is being edited by another user will be open in read-only mode. Once the user editing the form submits, or else abandons their editing by returning to Produce home, the form will once again be available for editing by another of the assignees in the parallel process.
In many cases, the form can be designed to require users in parallel to work on different parts of the form. In this case it is recommended to use conditions to only allow editing relevant form pages, sections and/or questions based on which workflow state is being worked on.
The Block Concurrent Editing setting can be turned off by selecting the Parallel section to reveal its properties in the Inspector panel.
Use with caution
It is recommended that you leave Block Concurrent Editing on when possible, and only turn off with caution once you've ensured that you are otherwise safeguarding from data loss by using conditions or some other method.
A transition from a state within a parallel workflow section can be specified as a Priority Parallel Exit transition. If the conditions for this transition are met when the task is submitted, the transition executes immediately, and any tasks parallel to the submitted task will be skipped. This allows, for example, for the workflow to be returned to the initiator without requiring consensus among parallel assignees.
In this example, if
Authorize 1 is allowed to authorize the workflow task without waiting for
Authorization 2, select the transition from
Authorize 1 to
(Finish) and enable the Priority Parallel Exit option.
Actions can also be added to a workflow to execute when:
- All exit transitions from a parallel section have completed.
- The state with the enabled Priority Parallel Exit option completed the task. These actions are added to the line that comes out of
Exit Parallel 1.
Assignment of parallel tasks to users must be specified in Design, or by question reference. Similarly, as states within a parallel section do not have a "Finish" page, user assignment for the transition out of a parallel section must be specified in Design, or by question reference.
Once all tasks in a parallel section have been completed, the transition out of the parallel section executes for all the parallel tasks concurrently, including resolution of question references. This means that even if, for example, State X is completed last - triggering the transition to another State - it could be State Y that includes the question defining the assignee for the new State.
If a parallel workflow task is terminated by an administrator, all other tasks within the same parallel section will also be terminated. This is to ensure that parallel tasks which rely on each other are not left in an unrecoverable state when some are terminated and some are not.
Reassignment of a parallel workflow task will affect only the selected task, leaving the other tasks in the parallel section alone. The parallel section will still complete as normal once all tasks (including reassigned tasks) are completed
A transition is the link between the end of one state and the beginning of another, creating forward (and backward) paths within a workflow. Transitions allow configuration of who the state will be assigned to, the correspondence that they will receive, along with some finer look-and-feel elements of the workflow.
Transitions display as as a connecting line, beginning with a circle from the outbound (from) state, and terminating with an arrow at the inbound (to) state. The line's appearance can vary depending on the type of transition, as follows:
- Grey unbroken line – Normal transition between two states
- Green unbroken line – Approved path transition from an Approval to another state
- Red broken line – Rejected path transition from an Approval to another state
There are several ways to add Transitions:
Option 1: On the workflow canvas, drag a transition between two states.
To initiate, hover over the source state to reveal a grey transition creation handle or, in the case of Approval states, there are green and red transition creation handles representing approved and rejected paths. Click and drag from the handle and release when the target state is highlighted.
If your target state is within a Parallel section, you can drag to the Parallel and the Create Transition dialog will display allowing you to select or create a state within that Parallel section.
Option 2: Drag and drop a Transition from the left panel.
To complete this method, click and drag the Transition block from the left panel and drag onto the source/starting state. The Create Transition dialog will display allowing you to select a destination state to complete the transition creation.
Option 3: Add a Transition from the Transitions tab of the source state.
Click to select the source/starting state for the transition, then click the Transitions tab. Under the Outbound section, click Add to reveal the Add Transition panel. Provide an optional name, and select the destination state, then click Create.
The new transition will be automatically selected to allow you to configure its properties in the Inspector panel.
Appears only when the transition is leaving an approval state and defines whether the transition applies if the approval is approved/rejected. Default is approved.
Approved/Rejected transitions will appear with a green/red dot respectively.
This section defines who the next state will be assigned to.
- Creator – Assign the state to the user who originally created the workflow.
- Current User – Assign the state to the user who is completing the current state, which creates a chain of states that need to be completed by a single user. This is often used to break bigger workflows into smaller chunks (part A, part B, etc.)
- Previous – Assign the state to the owner of the previous state, useful for returning workflows for edits.
- User – Assign the workflow to a specific User.
- Group – Assign the workflow to a specific Group.
- Unlock on Exit – When workflows states are assigned to a group, only one person can work on the form at a time. This means that when a user opens a workflow, this user locks the form to themselves. If the user does not complete the workflow in one session, this option, on by default, ensures that the workflow will be unlocked when the user leaves the forms enabling someone else in the group to continue working on the form.
- Temporary user – Assign the workflow to Guest or Anonymous users. For more information, refer to Temporary Users.
Send to Type only applies to user and group assignments and defines how the specific recipient should be selected.
- Specified – Pre-assign the workflow state to a particular user or group.
- Search – Provides an option where the user completing a form can search for a user or group of their choice.
- Question Reference – Links to a question reference that resolves to a named user or group to assign the workflow to. For example, a data connection could be used to determine an appropriate manager. References must resolve exactly to a specific username or group name.
Allows an in-progress workflow to be reassigned. When selected, select who will be given reassign rights:
- By Current Assignee – (Default) The person currently assigned to the workflow. This user can click the Reassign button from the Home page or a Dashboard.
- By Creator – Whoever submitted the first form
- By Previous Assignee – The person who assigned the workflow to the current assignee
The Creator and Previous Assignee user types can reassign from Produce > Form Activity for a workflow that they have are a part of.
Defines whether to send a notification email to alert the recipient that a workflow has been transitioned to them.
- Send Email (ON by default) – This will send an email to whoever the state is assigned to.
- Email Subject/Body – Content of the email
Communication Template Subject
If selecting an Email Communication Template for the Assignment email, the Email Subject on this screen will override the Subject on the Communication Template. To use the Communication Template Subject, remove the contents of the Email Subject option on this screen.
The Email Subject and Email Body have defaults that are the same as what currently gets sent for transitions. It also supports Question References as well as some keyword references. Here are some examples:
[ProjectLink]– Puts in a link to the task in Produce
[Comments]– The comments added before submission
[ProjectName]– Name of the Project
[StateName]– Name of the State that has been transitioned to
Reassignment of an active workflow changes the current task to a different user. This can be useful for ensuring active tasks can be completed when circumstances change. For example, the currently assigned user is on leave, or perhaps the current assignee determines that the task requires the expertise of someone else
Aside from these main use cases, there is also Temporary Users, allowing an external person to be issued temporary access to complete a given task.
Reassignment by end users in Produce must be configured in Design for each transition. Configuration as to which end users, if any, can reassign a workflow task is defined on the inbound workflow transition.
Reassignment configuration is only available for inbound transitions to a normal state, i.e. it does not apply for Approval or Event states. Only an administrator can reassign an Approval, see Reassign by a Workflow Administrator in Manage for more information. Event states do not support reassignment as they are assigned to external systems as opposed to individuals
In Design with your project open, find the inbound transition to the appropriate state and click to select. In the Inspector panel, enable the top level Allow Reassign setting and configure the granular user type options as described below:
|By Current Assignee (Default)||The user who currently owns the workflow task can reassign it to another user.|
Assignees can find the Reassign option by clicking the ellipsis (...) from the Forms Assigned To Me dialog.
|By Creator||The initiator of the workflow can reassign the open task to another user.|
Creators can find the Reassign option by clicking the ellipsis (...) from the Form Activity tab.
|By Previous Assignee||The assignee of the previous state can reassign the open task to another user.|
Previous assignees can find the Reassign option by clicking the ellipsis (...) from the Form Activity tab.
The currently assigned user can reassign a workflow task when granted permission from the Produce Home page, using the More Options (three-dot) menu next to the task name and clicking the Reassign option.
For previous assignees or creators of the workflow task, when the task is no longer on the Produce Home page, they can access the reassign option within the Form Activity screen.
When a user clicks Reassign from either Home or Form Activity, the Reassign Task screen appears, prompting for a target user and to provide a comment explaining the reassignment.
Optionally an email notification (on by default) will alert the target user of the reassign, providing them with the URL for their newly assigned task. Note that email notifications may be customized in the Communication Templates area of Manage.
How to assign workflow task to Temporary User
Temporary users can be used in a workflow transition. Enabling the Temporary User Save allows assigning a workflow task to a temporary user by providing an access code via email.
Provide question references to the following two fields to assign task to temporary user:
- Recipient Email
- Recipient Name
Add [AccessCode] within the Email body. This access code will allow the temporary user to complete the assigned workflow task received through provided email address.
Access Code can also be utilized within a transition action. This allows a user to deliver an access code by a different medium, such as push notification, custom action etc.
Access Code type has to be selected under Project Properties to place in the Email body
Access Codes must be unique
When using the Question Reference option to generate an access code, note that each access code must be unique. If you are self generating an access code use Sequences or some other algorithm that will guarantee a unique value. Forms that contain non-unique access codes will not submit.
The [AutoGenerated] option for Access Codes guarantees a unique code.
Note: take care when generating an access code using a sequence as these may be predictable and therefore not secure.
Reassign Temporary User Workflow task
Forms that involve workflows tasks assigned to temporary users can be recovered by reassigning within Manage.
- Open Manage and navigate to the Workflow section.
- Select the task and click "Reassign". Enter email address and name which will send an email to the temporary with a new project link and access code.
Page Title – Title of the page where the user decides assignment for next state.
Help Text – Help Text displayed on the final page where the assignment is defined by the user.
Show Next Steps – Displays Name of next State.
Show Comment – Default comment, which may contain question refences, included in comments textbox.
Comment Mandatory – Enforces user to provide a comment.
Default Comment – Default comment included in comments textbox.
Submit Button Text – Button Text.
Submitting Text – Text displayed while a form is submitting.
Redirect on Finish – When selected will prompt whether to go back to the home page or a particular form or URL after finishing the form.
- When redirecting to a URL, the particular URL will need to be specified whereas for redirecting to a project, properties can be specified (optional). See Project Properties for more information.
- When redirecting to Home, a message can be optionally displayed to the user to confirm their submission.
- Responses Submitted Title - Text shown in a heading font on the page after the user has submitted the responses.
- Responses Submitted Text - Text shown as a message on the page after the user has submitted the responses.
- Document(s) Allows the designer to specify documents to be available to be downloaded when the transition is triggered.
The document is only required to be selected here if the user will download it. Actions requiring the document to be generated are specified on the Action Documents tab of the Action itself.
- Downloads Title - Heading to be shown after the user submission page above the displayed documents.
Allows the designer to specify on which particular page the form will be loaded, often used for skipping content that is generally not relevant because it has been completed by another user, while still allowing the user to navigate back to said content.
In some cases, a state may have multiple transitions to other states. For example, if the workflow is an approval process and the workflow is approved, it will go to one state. If the approver doesn't approve, it may go to another state. This can be defined within the transition conditions.
Transition conditions work the same as all other conditions within SmartIQ. However, the only available condition type is Answer Value.
Actions can be added to transitions in a workflow by dragging an action from the left panel to the transition.
- Open the workflow canvas in Design.
- Select the workflow transition where one or more Action needs to occur.
- Click the Actions tab on the Inspector Panel.
- Select an action from the drop-down list.
- Click Create. The Action Properties are displayed.
Actions can be easily re-ordered via drag and drop, or using the Move Up and Move Down options in the More Options (...) menu. You can also copy Actions from the current transition to another one in the project using the More Options (...) menu.
When a workflow transitions between states, a number of operations are performed in order. These operations are separated into stages to allow for control over the ordering of Actions which are associated with the state.
The sequence of a workflow transition is as follows:
- Actions set to "Run After Submit" are executed
- Data stores are executed
- Documents are generated
- Actions set to "Run After Document Generation" are executed
- Next workflow state is created
- If the task is to be assigned to a Temporary User, the user is created
- Actions set to "Run After Workflow Assignment" are executed
- Notification of the workflow task is sent to the assigned user/group
- Escalations are generated and stored
- Actions set to "Run After Finish" are executed
The main stage of interest is usually Document Generation; Actions which run before this stage are unable to use generated documents but are able to generate documents for use by later actions. Actions which run after Document Generation are unable to have their documents used by other actions, but can make use of documents generated by Actions which ran earlier.
See the Actions Overview page for details of how to set an Action to run at a specific stage of the workflow generation.
Actions can be added to transitions in a workflow. There are some workflow only actions...
only cover the basics as linking back to the dedicated actions sections
SmartIQ Workflow allows configuring Escalation actions to be triggered based on configurable conditions.
- Open the Workflow canvas.
- Drag and drop the Escalation button from the left panel into the appropriate state or go to the Escalations tab of the state and click Add.
These are common properties for all available escalations:
Escalations are added to a queue when the state is created. The queue is processed at a 15-minute interval. A given escalation will be run at the next processing interval after the selected time has passed.
- Interval – Allows to define when this Escalation should be triggered, these are the options available:
- ASAP – Triggers the escalation task as soon as the task is added to the queue and the scheduler becomes available.
- In Minutes
- Min(s) after transition
- In Hours
- Hour(s) after transition
- In Days
- Day(s) after transition
- Weekdays Only
- Question (question reference to resolve 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.
- Retry On Failure – Allows the user to specify the number of retries and wait between retries. The escalation will be attempted again on failure the next time the scheduler runs. This may mean that it may not run at the exact delay specified, however it will never be shorter than that time period.
It is also possible to define recurring Escalations, selecting
Recurring option. Here a brief description of available options:
Range of Recurrence
- After Days
- On Date
- No End
A Webhook is a simple HTTP publish and subscription model for passing information between services. 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. Service response codes determine if the action is considered to have failed or completed. This action does not deal with the generated documents.
|Answer Values||Optional values and question references that you want to send to your service.|
|Custom Headers||Optional Custom Heathers included in the request.|
|Secret Key||User-provided API key that is sent to and validated by your service.|
|Webhook URL Endpoint||The URL of your service.|
Ability to send Push Notifications to the Offline App which has been registered to a user.
|Group Guid (Optional)||Send a push notification to every member of the group specified|
|Message||Body of the push notification to be sent|
|Title (Optional)||Title of the message to be sent|
|User Guid (Optional)||Send a push notification to the user specified|
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.
Allows reassigning current State to another User or Group.
|Group to Assign||SmartIQ Group to be reassigned.|
|User to Assign||SmartIQ User to be reassigned.|
Allows reassigning current State to another User or Group. For more information, refer to Escalations.
|Group to Assign||SmartIQ Group to be reassigned.|
|User to Assign||SmartIQ User to be reassigned.|
Sends an Email similarly to the Email Action with the difference that can be configured to be recurring using Escalation parameters.
|Email CC||(Carbon Copy) Put the email address(es) here if you are sending a copy for their information (and you want everyone to explicitly see this)||Optional|
|Email BCC||(Blind Carbon Copy) - Put the email address here if you are sending them a Copy and you do not want the other recipients to see that you sent it to this contact||Optional|
|Reply To||Email address to where recipients will reply escalation email.||Optional|
|Send To Assignee||Optional (defaults to True)|
The Assignee's email address will be the 'To' address in the email. If you use a CC or BCC and set this to false, the email will only go the recipients in the CC/BCC list.
Makes a request to a REST API every time the Escalation is triggered. For more information, refer to the Send to REST Service Action.
Required configuration in Manage > Connector Settings
This escalation has a required setting in Manage which sets the designated user to progress the workflow. If this is not set, the escalation will fail. See Connector Settings below for details.
A submit step escalation will progress a workflow from it's current state to a destination state. The escalation has the following input types:
|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 takes a key/value pair (migrated from a standard input) of a question and a value, for example, Key: |
|Target State List (name|name)||Accepts a pipe separated list of state names, for example "State 3|State 4", 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.|
- 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 an 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 user (from Connector Settings), so a "Current User" workflow transition will result in a task assigned to the Connector Settings service user.
|User Name||Sets the designated user to progress the workflow. Ideally this is a generic service user in the system (e.g. "AutoSubmit"). For auditing purposes this should not be a user who would otherwise be|
If the user is not set, the escalation will fail.
Terminates workflow when escalation Initiate condition is met. Note that this escalation can't be recurring as it will cancel the workflow once is initiated.
Updated 16 days ago