WF Programming¶
Workflows¶
Workflows are objects that describe activity patterns. Every workflow has a header and steps (WorkflowStep), which are set forth to be performed.
The header includes the following information:
Id – workflow identifier
Name (DisplayName)
Description (Description) – A more detailed description of what the workflow is used for
Group (GroupName) – Indicates to which group the workflow belongs
Max. running time (TimeOut) – Shows the maximum script running time (in seconds)
Scenario (Scenario) – A form template that is to be used to save the data (if needed)
Workflow instance and its statuses¶
A workflow can be executed by creating its instance (WorkflowInstance). One workflow can be launched in multiple parallel instances. Every instance has one of the following activity statuses (Activity):
New (New = 0) – A newly created instance that is waiting to be executed
Active (Active = 1) – An instance that is currently being executed
Paused (Paused = 5) – An instance, the execution of which has been suspended; subsequently, it can be activated again or cancelled
Successful (Succeeded = 10) – An instance that was completed without any errors
Failed (Failed = 20) – An instance that ended with errors
Timed out (TimeOut = 21) – An ended instance that exceeded the maximum run time
Cancelled (Canceled = 30) – An instance that was ended incomplete
Every instance has a start time (StartTimeUtc) and an end time (EndTimeUtc) indicated; in the Active status, the end time indicates a point of time by when the workflow needs to finish. The following parameters are available for parametric processing:
InstanceKey – A text value according to which the workflow can be branched
InstanceRefId – An ID that the workflow can use as a key reference to the object that is being processed by the workflow
ScenarioResultId – An ID of a data form that is connected with the workflow (optionally)
Result – A text value indicating the instance application result
ParentInstanceId – If an instance is executed as a subprocess of another instance, then this parameter indicates the ID of the superior instance
Executing a workflow¶
A workflow (WF) is typically executed based on a system event (e.g. Case status changed, a certain point of time was reached), with triggers (refer to the next chapter for a detailed description) used for this purpose. Practically, a workflow can also be executed by writing an entry in the WorkflowInstance table, with only the following two fields having to be completed:
WorkflowId – An identifier of the workflow that is to be executed
Activity – The value of “0” (New) needs to be entered
This causes a WF instance to be executed instantly. Optionally, it also makes sense to use the following fields:
InstanceKey – An optional instance parameter that can be used for conditional step execution (see below)
InstanceRefId – An optional instance parameter that can be freely used in steps
ScenarioResultId – If filled out, the instance will be executed with the given form; otherwise, a new form is created if it is specified in the workflow description
All other fields are used internally by a workflow instance engine, and their change will lead to a workflow malfunction.
Workflow steps - general¶
Workflow steps (WorkflowStep) have two types of parameters – generally valid fields with identical meanings for all step types, and fields with specific meanings.
General fields:
Name DisplayName |
A step name that is used for the administrator’s purposes; it should describe the instance purpose. |
Rank (Rank) |
The step rank, a flag. The system processes steps in an ascending order. If two steps have identical numbers, the system itself will determine their rank (which is not desirable). |
Action command (Action) |
A name of the action that is to be executed. |
Max. period (TimeOut) |
The maximum step duration in seconds. In some cases, it might not be used, while in other cases it may be required. |
Calendar mode (TimeMode) |
Time filter – a type of condition; if the time period is not valid, the step will be skipped. NULL means that the time condition is not evaluated. |
From (TimeFrom) |
The start date and time of the time condition. For DayInYear, the year is ignored, and for DayInWeek, just the day of the week is extracted. The field may be NULL only if TimeMode is also NULL. The local time is used. |
To (TimeTo) |
The end date and time of the time condition. For DayInYear, the year is ignored, and for DayInWeek, just the day of the week is extracted. The field may be NULL only if TimeMode is also NULL. The local time is used. |
(InstanceCondition) |
A condition for the InstanceKey value of the given instance. Any steps for which the condition is not fulfilled are completely left out from the processing. The condition is evaluated using SQL as follows: (InstanceCondition IS NULL OR InstanceKey LIKE InstanceCondition); the evaluation is performed always anew when the instance proceeds from one step to another. Note: No information is logged about the fact that a step has been skipped. |
The script normally proceeds in a sequence according to the Rank from one step to another. This linear execution can be changed using some action commands. The following fields are used to set the default branching options:
Jump target after timeout (TargetOnTimeOut) |
The jump target if the step times out (e.g. when the step TimeOut value is exceeded). If it is NULL, the script proceeds to the next step even if the step times out. |
Jump target after success (TargetOnSuccess) |
The jump target if the step is successful. If it is NULL, the script proceeds to the next step in sequence even if the step is successful. |
Jump target after failure (TargetOnFailure) |
The jump target if the step fails. If it is NULL, the script proceeds to the next step in sequence even if the step fails. |
Not all action commands use all three options, and the interpretation of success or failure is specific for each of the nodes.
Saving values do data set¶
The workflow with which the processing begins can create a data set (ScenarioResult). The scenario stated in the workflow header in the Scenario (ScenarioId) field is used as a template. All fields are created, and the data set is created as PreFilled. If the Scenario field is not completed, no data set will be created.
If a step saves a value to the data set, then it depends on the field type. If it is a selection field (Selecting from a drop-down list [DropDown], One answer from a list [RadioButtons], One answer with free text [RadioButtonsLastText], Multiple answers from a list [CheckBoxes], Multiple answers from a list with free text [CheckBoxesLastText]), then when saving, depending on the ResultText value, the system will try to find the ResultNumber value as well. Otherwise, it will save ResultText only.
Local server name¶
In some parameters (typically the URL), you can use the server name as the “##LSN##” macro; the server name is taken from the configuration file of the executing service (iCC.ServiceAsync). The option to use the “##LSN##” macro is always stated in the action command section for the relevant parameter. It concerns the following parameter:
<setting name="LocalServerName" serializeAs="String">
<value>localhost</value>
</setting>
Data in WorkflowEvent¶
All workflow instance operations are saved with information about the time of their occurrence, which instance it was (WorkflowInstanceId), and which step (WorkflowStepId) called them. The EventType field indicates the event type. Additional parameters are stored in the fields of AgentId (the agent who is connected with the operation), ReferenceData (text information), ReferenceId (reference). The Duration (duration in seconds) field indicates the duration of several event types.
Ordinary event types:
Start (Start = 0) – The workflow instance started
End (End = 1) – The workflow instance ended, and Duration indicates the total instance duration
Step success (StepSucceeded = 10) – The step ended successfully, and Duration can show the step duration
Step failure (StepFailed = 20) – The step failed, and Duration can show the step duration
Step timed out (StepTimeOut = 21) – The step ended with a timeout, and Duration can show the step duration
The step was skipped, there was a time discrepancy (StepSkipNoTime = 30) – The step was not executed at all; the TimeMode condition was not fulfilled
The step was interrupted during a parallel run (StepForkedOut = 31) – The step was being executed but another parallel branch was completed during its execution, and so it was no longer necessary to finish the step
The step was interrupted after result (StepResultedOut = 32) – The step was being executed but another run of the same instance tree executed the Result command and terminated all instances in the tree, and so it was no longer necessary to finish the step
TimeMode¶
The TimeMode field indicates how the TimeFrom/TimeTo fields are interpreted. If it is NULL, then the time is not checked.
DayInYear - Valid on a specific day in the year, every year, time from/to
SingleDay - Valid on a specific day (incl. year), time from/to
DayInWeek - Valid on a specific day of the week, every week, time from/to
NotDayInWeek – An inverse condition to DayInWeek, i.e. not valid on a specific day of the week, every week, time from/to
When entering the “from” time, the system will set seconds to 00.0, while for the “to” time it will set seconds to 59.9.
Example for entering the entire morning: 8:00 until 11:59
Workflow Steps¶
Delay (Delay)¶
This action command delays the workflow instance for a specified period of time. The period can be defined either statically in the TimeOut parameter or dynamically as a data set field name in the Targets parameter. If neither of the two is defined, the step will end with an error. If both values are defined and the data set field contains valid data, then it has a priority (and TimeOut then serves as an alternative value). If the interval is smaller than zero, the step will end with an error. if the interval equals zero, the step will fail and a jump to TargetOnFailure will follow; otherwise, after a delay the script will jump to TargetOnSuccess. The Parameters field can be used to enter a unit of time that is to be used to calculate the delay; if no unit is specified, the default unit will be the second.
Max. period (TimeOut) |
A period of delay defined in the selected unit of time. An optional parameter. |
Target values (Targets) |
A name of the data set field that contains a number – a delay in seconds. An optional parameter. |
Parameters (Parameters) |
A unit of time; if not specified, the second is used. The value is case sensitive. s – second m – minute h – hour d – day w – week M – month [use the .NET function of DateTime.AddMonths, e.g. 31 Jan 2017 + 1 month = 28 Feb 2017] y – year [uses the .NET function of DateTime.AddYears, e.g. 29 Feb 2016 + 1 year = 28 Feb 2017] |
Possible events¶
StepSucceeded, StepFailed
Gosub (Subprocess)¶
This action command calls another workflow instance and then waits for this workflow to finish. The sub-instance will share the same ScenarioResultId data set as the calling instance, i.e. no new one will be created, and InstanceKey will also be set identically. The step may be either successful (the sub-instance ended without errors), failed (the sub-instance failed), or timed out (the sub-instance could not finish within the set time limit).
Max. period of time (TimeOut) |
A maximum waiting time (in seconds) for the sub-workflow to finish. A mandatory parameter. |
Target ID (TargetId) |
An ID of the workflow that is to be executed. A mandatory parameter. |
Reference ID (ReferenceId) |
If entered, it will be set for the sub-workflow as its InstanceRefId. This setting has priority over Parameters. If it is NULL, the same InstanceRefId will be set as with the calling instance. |
Parameters (Parameters) |
A name of the data set field that is to be used as a value source for InstanceRefId. NULL means that the option is not used. |
Possible events¶
StepSucceeded, StepFailed, StepTimedOut
ForkJoin (Subprocesses)¶
This action command calls instances of another one or two workflows and waits until one or both workflows end. The sub-workflow will have a new data set of ScenarioResultId, which can be filled based on the scenario consolidation rules (ScenarioConsolidation). InstanceKey and InstanceRefId will be set identically. The step may be successful (the sub-instances ended without errors), fail (the sub-instance failed), or time out (the sub-instance could not finish within the set time limit).
Max. period of time (TimeOut) |
A maximum waiting time (in seconds) for the sub-workflow to finish. A mandatory parameter. |
Target ID (TargetId) |
An ID of the first workflow that is to be executed. A mandatory parameter. |
Reference ID (ReferenceId) |
An ID of the second workflow that is to be executed. NULL means that just one sub-workflow is called. |
Reference number (Reference) |
Step completion indication: NULL – The step waits for both workflows to finish 1 – The step waits for one workflow to finish, while the other one is cancelled (Cancel) Any other number – An invalid value |
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, StepForkedOut
Goto (Branching)¶
This action command makes it possible to change the program run. The script jumps to a target in TargetOnSuccess. Apart from the TimeMode and the InstanceCondition conditions, it is also possible to use the TimeOut field – when this condition is fulfilled, the script jumps to TargetOnTimeOut. If the jump target number is higher than the rank of any script step, it will be terminated without any entry being made in the Result field.
Max. period of time (TimeOut) |
A control limit in seconds. If specified and if the instance is already running for a longer period of time, the command takes the same jump as when timed out. |
Jump target after success (TargetOnSuccess) |
An ordinary jump target. If not filled out, the command continues with the next step. |
Jump target after timeout (TargetOnTimeOut) |
A jump target when the time limit is exceeded. If not specified, the command continues with the next step. |
Possible events¶
StepSucceeded, StepTimedOut
Holiday (Branching on public holidays)¶
This action command allows you to change the program run. Apart from the TimeMode time condition, the Parameters field is also used to determine a group of public holidays from the holiday table. If the current local time is included in the group validity, a jump to TargetOnSuccess follows; otherwise, the script jumps to TargetOnFailure.
Parameters (Parameters) |
A name of a public holiday group that is used to determine holiday validity. |
Jump target after success (TargetOnSuccess) |
An ordinary jump target. If not filled out, the command continues with the next step. |
Jump target after timeout (TargetOnTimeOut) |
A jump target when the time limit is exceeded. If not specified, the command continues with the next step. |
Possible events¶
StepSucceeded, StepFailed
SetInstanceKey (Set to key)¶
This action command sets a value of the key related with the instance (InstanceKey).
Parameters (Parameters) |
A value that is to be set. It is taken literally; an empty value means NULL. |
Possible events¶
StepSucceeded
SetResult (Set to result)¶
This action command sets an instance result value (Result), yet the instance continues.
Parameters (Parameters) |
A value that is to be set. It is taken literally; an empty value means NULL. |
Possible events¶
StepSucceeded
SetTarget (Set to column)¶
This action command sets a data set field value.
Target values (Targets) |
A name of a data set field to which the value is to be saved (TargetColumn). Example: “Membership” |
Parameters (Parameters) |
“##WorkflowInstanceId##” – an ID of the running instance “##InstanceKey##” – a key related to the instance “##InstanceRefId##” – an ID related to the instance “##Result##” – the current value of the instance result field (Result) “##StartTime##” – the instance start time (local time) “##CurrentTime##” – the current local time at the moment of command execution |
Possible events¶
StepSucceeded
SwitchTarget (Branching by column)¶
This action command allows you to change the program run. Apart from the TimeMode time condition, the Parameters field is also used to indicate a value that needs to be contained in a selected data set column. The Targets field indicates a name of the data set column that should contain the given value. If the condition is fulfilled, the script jumps to TargetOnSuccess; otherwise, the script jumps to TargetOnFailure.
Parameters (Parameters) |
The value that is to be compared. It uses the SQL LIKE syntax. If it contains the special value of ##Empty##, then the condition applies if the data set field equals an empty string. If it is empty, then the condition applies if the field contains NULL. Example: “1000%” Example: “” [test for NULL] |
Target values (Targets) |
Data set column name. Example 1: “Membership” Example 2: “c_card” |
Possible events¶
StepSucceeded, StepFailed
SwitchDb (Branching by DB)¶
First option is a command, that performs a parametric query using the ODBC mechanism over a selected data source; the returned values are recorded in a data set fields (ScenarioResult) or variables, provided that the field names match those in TargetColumn or name of existing variable (without % prefix). If the IvrApplyQueryResultToNullOnly configuration parameter is selected, only those fields are overwritten that have the NULL value. Windows and Linux supported. Used for on-premise installations with additional ODBC drivers.
The second option is ADO.NET connection. With this option, you can’t use the full connection string, but instead, the one set in appsettings.json will be used (file according to the background service). Used for container installations.
Note 1: All parameters are submitted and returned as text nvarchar.
Note 2: This command can also be used to carry out customer calculations using the SQL Server
File name (FileName) |
A connection string for the ODBC provider. More info: https://www.connectionstrings.com/microsoft-odbc-driver-17-for-sql-server/ Example for SQL Server 2019: Driver={ODBC Driver 17 for SQL Server};Server=myServerAddress;Database=myDataBase;UID=myUsername;PWD=myPassword A connection string for the ADO provider. Example:
|
Parameters (Parameters) |
Names of data set fields (TargetColumn), the values of which will be used as the query parameters. The separating characters are commas or semicolons. The parameter sequence determines their insertion in the ODBC command. Special parameters: “##WorkflowInstanceId##” – an ID of the running instance “##InstanceKey##” – a key related to the instance “##InstanceRefId##” – an ID related to the instance “##Result##” – the current value of the instance result field (Result) “##ScenarioResultId##” – an ID of the data set related to the instance “##StartTime##” – the instance start time (local time) “##CurrentTime##” – the current local time at the moment of command execution “##None##” – no parameter Example 1: “MemberNumber” Example 2: “MemberNumber,##Result##” |
Target values (Targets) |
A parametric ODBC command suitable for the given provider. The parameters are marked with " ? " and submitted to the query based on the sequence. Example 1: “exec FindMember ?” Example 2: “SELECT * FROM Membership WHERE Id=?” ADO.Net usage: Example: ” SELECT * FROM Membership WHERE Id=@MemberNumber” |
Possible events¶
StepSucceeded, StepFailed, StepTimedOut
QueryDb (Query to DB)¶
First option is a command, that performs a parametric query using the ODBC mechanism over a selected data source; the returned values are recorded in a data set fields (ScenarioResult) or variables, provided that the field names match those in TargetColumn or name of existing variable (without % prefix). If the IvrApplyQueryResultToNullOnly configuration parameter is selected, only those fields are overwritten that have the NULL value. Windows and Linux supported. Used for on-premise installations with additional ODBC drivers.
The second option is ADO.NET connection. With this option, you can’t use the full connection string, but instead, the one set in appsettings.json will be used (file according to the background service). Used for container installations.
Note 1: All parameters are submitted and returned as text nvarchar.
Note 2: This command can also be used to carry out customer calculations using the SQL Server
File name (FileName) |
A connection string for the ODBC provider. More info: https://www.connectionstrings.com/microsoft-odbc-driver-17-for-sql-server/ Example for SQL Server 2019: Driver={ODBC Driver 17 for SQL Server};Server=myServerAddress;Database=myDataBase;UID=myUsername;PWD=myPassword A connection string for the ADO provider. Example:
|
Parameters (Parameters) |
Names of data set fields (TargetColumn), the values of which will be used as the query parameters. The separating characters are commas or semicolons. The parameter sequence determines their insertion in the ODBC command. Special parameters: “##WorkflowInstanceId##” – an ID of the running instance “##InstanceKey##” – a key related to the instance “##InstanceRefId##” – an ID related to the instance “##Result##” – the current value of the instance result field (Result) “##ScenarioResultId##” – an ID of the data set related to the instance “##StartTime##” – the instance start time (local time) “##CurrentTime##” – the current local time at the moment of command execution “##None##” – no parameter Example 1: “MemberNumber” Example 2: “MemberNumber,##Result##” |
Target values (Targets) |
A parametric ODBC command suitable for the given provider. The parameters are marked with " ? " and submitted to the query based on the sequence. Example 1: “exec FindMember ?” Example 2: “SELECT * FROM Membership WHERE Id=?” ADO.Net usage: Example: ” SELECT * FROM Membership WHERE Id=@MemberNumber” |
Possible events¶
StepSucceeded, StepFailed
QueryUrlText (Query for URL as text)¶
Performs a parametric query using the http/https GET mechanism for the entered web server, and then processes the returned value as a single text value and, if relevant, writes it in the data set (ScenarioResult) in a field of the name specified in Targets (the TargetColumn field). If there is no script associated with the WF or Parameters is empty, only the URL will be called. If Targets does not contain the target field, the returned http response is discarded.
Note 1: All parameters are submitted as text within the Query String or as placeholders. Note 2: This command can also be used to write and update values using the web server.
Reference text ReferenceText |
The primary URL address for which parameters are submitted as a Query String: Parameter example: “https://www.atlantis.cz/OrderStatus.aspx” Example of a sent URL with the parameter values of lang=”cz” and number=”41547”: “atlantis.cz/OrderStatus.aspx?lang=cz&number=41457” The primary URL address for which parameters are submitted in the place of placeholders: Parameter example: “www.atlantis.cz/{lang}/{number}?Id={InstanceRefId}” Example of a sent URL with the parameter values of lang=”cz” and number=”41547”: “https://www.atlantis.cz/cz/41457” Note: Special parameters are stated in braces without the # characters; it is necessary to avoid a collision of names and the form. The address can contain the ##LSN## macro-element. |
Parameters (Parameters) |
“##WorkflowInstanceId##” – an ID of the running instance “##InstanceKey##” – a key related to the instance “##InstanceRefId##” – an ID related to the instance “##Result##” – the current value of the instance result field (Result) “##ScenarioResultId##” – an ID of the data set related to the instance “##StartTime##” – the instance start time (local time) “##CurrentTime##” – the current local time at the moment of command execution “##None##” – no parameter Example 1: “MemberNumber” Example 2: “MemberNumber,##Result##” |
Target values (Targets) |
A name of the data set field to which the text returned by means of http is to be saved. Optionally also a username and password (the values are separated with semicolons). Example 1: “MemberNumber” Example 2: “MemberNumber;system;ws7787!P” It is also possible to use the special value of “SSPI”, in which case an integrated login is used under the Windows account under which the iCC synchronous service is running. Example 3: “MemberNumber;SSPI” |
Reference ID (ReferenceId) |
Any value – uses the URL followed by a Query String An empty value – placeholders are used with the format of {name} Example: “00000000-0000-0000-0000-000000000000” |
Reference number (Reference) |
A code page used for the response; examples (depending on the installed server version): empty – auto-detection 1250 – Windows 1250 852 – DOS 852 65001 – UTF8 |
Possible events¶
StepSucceeded, StepFailed
QueryUrlJson (Query for URL as JSON)¶
Performs a parametric query using the http/https mechanism for the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org) and records the result in the data set (ScenarioResult), provided that there are identical TargetColumn field names.
Note 1: All parameters are submitted and returned as text within the Query String or as placeholders. Note 2: This command can also be used to write and update values using the web server.
Reference text (ReferenceText) |
“atlantis.cz/OrderStatus.aspx?lang=cz&number=41457”
|
Parameters (Parameters) |
“##WorkflowInstanceId##” – an ID of the running instance “##InstanceKey##” – a key related to the instance “##InstanceRefId##” – an ID related to the instance “##Result##” – the current value of the instance result field (Result) “##ScenarioResultId##” – an ID of the data set related to the instance “##StartTime##” – the instance start time (local time) “##CurrentTime##” – the current local time at the moment of command execution “##None##” – no parameter Example 1: “MemberNumber” Example 2: “MemberNumber,##Result##” |
Target values (Targets) |
A username and password if it is to be used for a general http/s authentication, separated with a semicolon. Example 1: “system;ws7787!P” It is also possible to use the special value of “SSPI”, in which case an integrated login is used under the Windows account under which the iCC asynchronous service is running. Example 2: “SSPI” If it is necessary to send a basic authentication without the 401/WWW-Authenticate handshake, then the following prefix can be added before the username: “!PRE!” Example 3: “!PRE!system;ws7787!P” If JWT authentication is to be used, then the following prefix can be added before the username: “!JWT!”. The authentication server URL needs to be added as a third parameter. The JSON parameters submitted in the header have the following format: The parameters submitted as payload are as follows: Example 4: “!JWT!interop;jjud48e;https://adfs.server.com/login” |
Reference ID (ReferenceId) |
The GUID value starting with “99999999” – placeholders are used with the format of {name} and parameters from Parameters are submitted as a “flat” JSON structure in the body of the HTTP POST request. Any other value – a URL address is used, followed by a Query String (HTTP GET) An empty value – placeholders are used with the format of {name} (REST HTTP GET) Example: “00000000-0000-0000-0000-000000000000” |
Reference number (Reference) |
A code page used for the response; examples (depending on the installed server version): empty – auto-detection 1250 – Windows 1250 852 – DOS 852 65001 – UTF8 |
Possible events¶
StepSucceeded, StepFailed
PostContact (Send contact as JSON)¶
This action command sends the contact data in the ContactRest structure using the http/https POST mechanism to the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org) and records the result in the data set (ScenarioResult), provided that there are identical TargetColumn field names. If no data set is associated with the instance, then nothing is saved.
Note: For a description of the ContactRest structure, please refer to “iCC- REST-JSON integration”.
The node assumes that InstanceRefId contains a ContactId of the contact that is to be sent in the POST body in the JSON format in the ContactRest structure.
The parameters ReferenceText, Targets, Reference and the entire subsequent processing is the same as with the QueryUrlJson node, including the uploading of returned data to the form fields.
PostIssue (Send issue as JSON)¶
This action command sends the case data in the IssueRest structure using the http/https POST mechanism to the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org) and records the result in the data set (ScenarioResult), provided that there are identical TargetColumn field names. If no data set is associated with the instance, then nothing is saved.
Note: For a description of the IssueRest structure, please refer to “iCC- REST-JSON integration”.
The node assumes that InstanceRefId contains an IssueId of the issue that is to be sent in the POST body in the JSON format in the IssueRest structure.
The parameters ReferenceText, Targets, Reference and the entire subsequent processing is the same as with the QueryUrlJson node, including the uploading of returned data to the form fields.
PostOutboundCall (Send outbound call as JSON)¶
This action command sends the outbound call data in the OutboundCallRest structure using the http/https POST mechanism to the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org) and records the result in the data set (ScenarioResult), provided that there are identical TargetColumn field names. If no data set is associated with the instance, then nothing is saved.
Note: For a description of the IssueRest structure, please refer to “iCC- REST-JSON integration”.
The node assumes that InstanceRefId contains an OutboundCallld of the call that is to be sent in the POST body in the JSON format in the OutboundCallRest structure.
The parameters ReferenceText, Targets, Reference and the entire subsequent processing is the same as with the QueryUrlJson node, including the uploading of returned data to the form fields.
PostMessage (Send message as JSON)¶
This action command sends the message data in the MessageRest structure using the http/https POST mechanism to the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org) and records the result in the data set (ScenarioResult), provided that there are identical TargetColumn field names. If no data set is associated with the instance, then nothing is saved.
Note: For a description of the MessageRest structure, please refer to “iCC- REST-JSON integration”.
The node assumes that InstanceRefId contains an Messageld of the message that is to be sent in the POST body in the JSON format in the MessageRest structure.
The parameters ReferenceText, Targets, Reference and the entire subsequent processing is the same as with the QueryUrlJson node, including the uploading of returned data to the form fields. Other parameters used:
Parameters (Parameters) |
Options, that can modify what is sent: ##WithBinary## – if specified, then field BinaryContent64 is filled, otherwise only metadata of attachments are supplied |
PostForm (Send form as JSON)¶
This action command sends the form data in the FormRest structure using the http/https POST mechanism to the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org). If no data set is associated with the instance, then nothing is saved.
Note: For a description of the MessageRest structure, please refer to “iCC- REST-JSON integration”.
The node assumes that InstanceRefId contains an Messageld of the contact that is to be sent in the POST body in the JSON format in the MessageRest structure.
The parameters and the entire subsequent processing is the same as with the QueryUrlJson node, including the uploading of returned data to the form fields.
PostEntities (Send entities as JSON)¶
This action command sends the array of entities in the EntityRest structure using the http/https POST mechanism to the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org) and records the result in the data set (ScenarioResult), provided that there are identical TargetColumn field names. If no data set is associated with the instance, then nothing is saved.
Note: For a description of the EntityRest structure, please refer to “iCC- REST-JSON integration”.
The node assumes that InstanceRefId contains an ld that parameter for a DataQuery. Selection of entities is determined by executing custom DataQuery which is supplied an parameter @RecordId. The DataQuery has to return two colums: Id – Guid of entity and EntityType – name of the entity (literal text – one of list “Contact”, “Issue”, “Message”, “OutboundCall” or “Form”). Selected entities are then extracted into their respective REST structures and sent in the POST body in the JSON format as array of EntityRest structures.
The parameters ReferenceText, Targets, Reference and the entire subsequent processing is the same as with the QueryUrlJson node, including the uploading of returned data to the form fields. Other parameters used:
Parameters (Parameters) |
Options, that can modify what is sent: WithBinary – if specified, then field BinaryContent64 are filled, otherwise only metadata of attachments are supplied WithForms – if specified, then associated forms for entities OutboundCall and Message are filled with Data, otherwise only Ids and Scenarios are filled in their FormRest structure. When entity of type Form is to be exported by result from DQ, it always contains Data. |
TargetId |
Id of DataQuery that is used to obtain a list of exported entities. |
PostDataQuery (Send DQ data as JSON)¶
This action command sends the array of JSON obejcts in structure reflecting DQ definition using the http/https POST mechanism to the entered web server, and then processes the returned values as a single record in the JSON format (http://www.json.org) and records the result in the data set (ScenarioResult), provided that there are identical TargetColumn field names. If no data set is associated with the instance, then nothing is saved.
Note: For a description of the structure, please refer to “iCC- REST-JSON integration”.
The node assumes that InstanceRefId contains an ld optional parameter for a DataQuery. Selection of data is determined by executing custom DataQuery which is supplied an parameter @RecordId. Sort order is done according to DataQuery default sorting settings. Returned colums are all defined DataQueryColums except for models Css, Color, Bold, QueryText, QueryId, Command and Toggle. Data are formatted as JSON retaining their data type. No formatting or conversion is performed, with exception of DateTimeUtc model, which is converted to server local time. JSON objects have properties named according to DataQueryColum DisplayName and they are then sent in the POST body as JSON array.
Note: There is no way to specify additional column filters in this node, which is different from REST functionality.
The parameters ReferenceText, Targets, Reference and the entire subsequent processing is the same as with the QueryUrlJson node, including the uploading of returned data to the form fields. Other parameters used:
TargetId |
Id of DataQuery that is used to obtain a list of exported entities. |
SendEmail (Send e-mail with report)¶
This action command sends a message (e-mail, SMS, fax) to the addresses specified in Targets based on the ReferenceId template and, if relevant, attaches a downloaded file (applicable to e-mail messages only). ReferenceText is used as the message subject, and the message is sent beyond the gateway specified in TargetId.
Target ID (TargetId) |
An ID of the gateway beyond which the message is to be sent. |
Target values (Targets) |
Direct target addresses to which the message is to be sent, separated with commas, or a name of the data set field (TargetColumn), the value of which will be used as the sender’s address (it can contain multiple addresses separated with commas). If Targets contains at least one @ character or starts with +, then the text is considered as a direct address (e.g. telephone number). Example 1: “ReportEmail” Example 2: “info@atlantis.cz” Example 3: “+420602330533” |
Reference text ReferenceText |
A text (plain) that is to be used as the message subject. The text will be macro-expanded according to the relevant scenario (expansion of $Result…:TargetColumn$). |
References |
Can be specified a timeout for downloading a report. Optional time in seconds. Example: “120” |
Reference ID (ReferenceId) |
An ID of an e-mail or generic template that will be used for the message body; the message macro-parameters will be expanded ($Result…:TargetColumn$); if nothing is filled out, the message will have an empty body. The template will not be used for the SMS channel. Example: “33B2BBC5-46CC-E411-855A-0811968B9484” |
Parameters (Parameters) |
Parameters for downloading a file (e.g. a report) that will be attached to the message as its attachment. It is a JSON structure with two parameters:
A URL address for which parameters are submitted in place of placeholders: Parameter example: “www.atlantis.cz/{lang}/{number}?x={##InstanceKey##}” An example of a sent URL with the following parameters: lang=”cz” and number=”41547”: “https://www.atlantis.cz/cz/41457” The following special parameters are available as well: “##WorkflowInstanceId##” – an ID of the running instance “##InstanceKey##” – a key related to the instance “##InstanceRefId##” – an ID related to the instance; if it is a WF for paging, then it is a Paging ID; if it is a member paging WF, then it is a PagingMember ID “##Result##” – the current value of the instance result field (Result) “##ScenarioResultId##” – an ID of a data set related to the instance “##StartTime##” – the instance start time (local time) “##CurrentTime##” – the current local time at the moment of command execution Credentials – a username and a password, if it is to be used, separated with a semicolon Example: “system;ws7787!P” It is also possible to use the special value of “SSPI”, in which case an integrated login is used under the Windows account under which the iCC asynchronous service is running. The attachment is generated just for the e-mail channel. If the field is empty, then no attachment is generated. |
Possible events¶
StepSucceeded, StepFailed
SendUdp (Send a UDP message)¶
This action command sends a UDP text message to the address specified in ReferenceText or Targets and to the port indicated in Reference. The text in Parameters is used as a specimen, with the data being macro-expanded. The message is sent from a local IP address that is specified in the asynchronous service configuration file in the SendUdpLocalAddress key and from the SendUdpLocalPort port. The message will be sent with the UTF8 encoding, i.e. if it contains just ASCII characters, it will be equivalent to ASCII encoding.
Target values (Targets) |
A name of a data set field (TargetColumn), the value of which will be used as the target address. Example: “TargetComputer” |
Reference text (ReferenceText) |
A fixed IP address or field name from which the address is to be taken. If Targets is not used, then this field is used. Example 1: “192.168.1.200” Example 2: “infoserver” |
Reference number (Reference) |
A fixed port to which the message will be sent. Example 1: “12400” |
Parameters (Parameters) |
The outbound message text with parameters macro-expanded in the same way as with an e-mail message. Parameter example: “{“Caller”:”$ResultTe xt:number$”,”InboundCallId”:”$ResultText:id$”}” |
Possible events¶
StepSucceeded, StepFailed
Return (Return)¶
This command terminates the current script run and makes a relevant entry in the Result field. It does not terminate any other scripts.
Parameters (Parameters) |
The resulting value that is to be recorded. |
Possible events¶
StepSucceeded
Result (Result)¶
This action command looks up the root instance of the current instance (unless it is the instance itself) and terminates the entire instance tree (including the current script). The root instance result is filled with the Result field content.
Parameters (Parameters) |
The resulting value that is to be recorded. |
Possible events¶
StepSucceeded, StepResultedOut
EmailQuestion (E-mail question)¶
This action command creates and sends an outbound e-mail message and waits for a response for a pre-defined period of time. The e-mail message is sent to the address specified in the InstanceKey field of the current instance. If the message cannot be sent or a response is not received within the given period of time, the script jumps to TargetOnTimeOut.
Reference ID (ReferenceId) |
An ID of the gateway beyond which the message is to be sent. |
Reference text (ReferenceText) |
A text (plain) that is to be used as the message subject. The text will be macro-expanded according to the relevant scenario and implicit parameters. |
Parameters (Parameters) |
A text (html) that is to be used as the message body. The text will be macro-expanded according to the relevant scenario and implicit parameters. Refer to the Message module description. |
Max. period of time (TimeOut) |
A period of waiting for a response |
Target ID (TargetId) |
If filled out, then it is an ID of TextMatchRule that is to be used to evaluate the response; depending on the result, either TargetOnSuccess or TargetOnFailure is called (if it is NULL, it is always successful). |
Reference number (Reference) |
A response processing indicator.
NULL – No action
0 – Mark the response as read 1 – Mark the response as settled and close it |
Note: A response is recognized based on the InReplyTo connection identifier in the e-mail, which leads to a relation to the original message using RelatedMessageId. If the setting indicates that the response that has been found should be closed (1), then just active messages are searched.
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, MessageSent
CallQuestion (Telephone call question)¶
This action command creates and starts an outbound call either using IVR or manually, and for a pre-defined period of time it waits for a response in the form of IvrResponseA or AppResult. The call is routed to the number indicated in the InstanceKey field of the current instance. If the call fails or the response does not come timely, then TargetOnTimeOut is called.
Reference ID (ReferenceId) |
An ID of the campaign (OutboundList) that is to be used for the call |
Target ID (TargetId) |
An ID of the IVR script that is to be used for the call (IvrScriptA). If it is NULL, a manual call will be scheduled. |
Max. period of time (TimeOut) |
A period of waiting for a response |
(ReferenceText) |
If this parameter is filled out, the IVR processing result (IvrResponseA) or manual result (AppResult) is compared with this value. If the values are identical, then TargetOnSuccess is called, otherwise it is TargetOnFailure (if it is NULL, it is always successful). |
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, CallMade
SmsQuestion (SMS question)¶
This action command creates and sends an outbound SMS message and waits for a response for a pre-defined period of time. If the SMS sending fails or the response does not come timely, then TargetOnTimeOut is called.
Reference ID (ReferenceId) |
An ID of the gateway beyond which the message is to be sent. |
Parameters (Parameters) |
A text that is to be used as the message (). The text will be macro-expanded according to the relevant scenario and implicit parameters. Refer to the Message module description. |
Max. period of time (TimeOut) |
A period of waiting for a response |
Reference text (ReferenceText) |
A reference text in the response that is to be considered as acceptance (it is not case sensitive) in the LIKE syntax. TargetOnSuccess is called. |
Target values (Targets) |
A reference text in the response that is to be considered as a rejection (it is not case sensitive) in the LIKE syntax. TargetOnFailure is called. |
Reference number (Reference) |
Response processing indicator.
NULL – No action
0 – Mark the response as read 1 – Mark the response as settled and close it |
Note: A response is identified according to an identical telephone number and also by the fact that it contains either a text from ReferenceText or from Targets. Other SMS messages from the given telephone number or not considered as valid responses. If the setting indicates that the response that has been found should be closed (1), then just active messages are searched.
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, MessageSent
ForkJoinPaging (Paging subprocesses)¶
This action command calls other workflow instances based on the information specified in the Paging and the PagingMember tables and waits until the required number of workflows ends. A subinstance will have a new data set of ScenarioResultId, which can be filled out based on the scenario consolidation rules (ScenarioConsolidation). It expects InstanceRefId to contain a reference to the Paging record, then creates a subprocess for every root member from PagingMember, and to this subprocess it then submits a reference to it in InstanceRefId. The step can be either successful (all subinstances finished without errors), it can fail (the subinstance fails), be timed out (the subinstance could not finish timely). The InstanceKey is inherited for any subprocesses.
Target ID (TargetId) |
An ID of the workflow, the instances of which are to be launched for the paging root members. A mandatory parameter. |
Reference number (Reference) |
An indication of step completion: NULL – The step waits for all workflows to finish A positive number – The steps waits for the indicated number of workflows to finish; all other workflows are cancelled |
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, StepForkedOut
ForkJoinSubstitutes (Substitute subprocesses)¶
This action command calls other workflow instances of the current member’s substitutes based on the information specified in the PagingMember table and waits until the required number of workflows end. A subinstance will have a new data set of ScenarioResultId, which can be filled out based on the scenario consolidation rules (ScenarioConsolidation). It expects InstanceRefId to contain a reference to the PagingMember record, then creates a subprocess for every substitute member from PagingMember, and to this subprocess it then submits a reference to it in InstanceRefId. The step can be either successful (all subinstances finished without errors), it can fail (the subinstance fails), be timed out (the subinstance could not finish timely). The InstanceKey is inherited for subprocesses. Optionally, the member’s current status can be changed to TimedOut.
Target ID (TargetId) |
An ID of the workflow, the instances of which are to be launched for the paging root members. A mandatory parameter. |
Reference number (Reference) |
An indication of step completion: NULL – The step waits for all workflows to finish A positive number – The steps waits for the indicated number of workflows to finish; all other workflows are cancelled |
Reference text (ReferenceText) |
If it contains the “TimedOut” value, then when the step is started, the calling member’s status is changed to “TimedOut”, provided that it was still in the status of “Pending”. If there is any other value, the substituted member’s status will not be changed. |
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, StepForkedOut
CallPaging (Telephone call paging)¶
This action command creates and starts an outbound call either using IVR or manually, and for a pre-defined period of time it waits for a response in the form of IvrResponseA or AppResult. It expects that InstanceRefId includes a reference to PagingMember. The call is routed to the number indicated in the Phone1,2,3 field of the paging member. If the call fails or the response does not come timely, then TargetOnTimeOut is called. The called IVR script can explicitly use the node of PromptPaging, which finds information from the ongoing paging.
Reference ID (ReferenceId) |
A campaign ID (OutboundList) that is to be used for the call; however, ProjectId will always be used according to the Paging settings; Skill is set to 0. |
Target ID (TargetId) |
An ID of the IVR script that is to be used for the call (IvrScriptA). If it is NULL, then a manual call will be scheduled. |
Reference number (Reference) |
A selection indicating which field is to be used. The value of 1,2,3 selects Phone1,2,3. No other values are allowed; it is a mandatory parameter. If the relevant field is not filled out, the script jumps to TargetOnTimeOut. |
Max. period of time (TimeOut) |
A period of waiting for a response |
Reference text (ReferenceText) |
Acceptance. If the field is filled out, then the IVR processing result (IvrResponseA) or the manual result (AppResult) is compared with this value. If there is a match, then TargetOnSuccess is called (if it is NULL, it is not evaluated). |
Target values (Targets) |
Rejection. If the field is filled out, then the IVR processing result (IvrResponseA) or the manual result (AppResult) is compared with this value. If there is a match, then TargetOnSuccess is called (if it is NULL, it is not evaluated). |
Note: If nothing is filled out or there is no match with either ReferenceText or Targets and the call result is not NULL, then TargetOnTimeOut is called. The comparison is not case sensitive.
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, NoPagingData
SmsPaging (SMS paging)¶
This action command creates and sends an outbound SMS and for a pre-defined period of time it waits for a response. It expects that InstanceRefId includes a reference to PagingMember. The SM is sent to the number indicated in the Phone1,2,3 field of the paging member. If the SMS sending fails or the response does not come timely, then TargetOnTimeOut is called. The SMS text is based on the Paging.SmsText field of the relevant paging, with the following codes being macro-expanded:
##AC## - replaced with Paging.SmsAcceptCode
##RC## - replaced with Paging.SmsRejectCode
##DL## - replaced with date and time, whereby the step waits for a response to come (based on the TimeOut value and, if relevant, maximum script run time).
The response must be processed by the “SmsPagingResponse (Find an SMS code and decide on response)” IMR node, which identifies the inbound message according to a matching telephone number and the fact that it contains either the text from SmsAcceptCode or from SmsRejectCode. Any other SMS messages from the given telephone number are not considered to be a valid response. Any response found is always closed, and only active messages are searched. For a message sent by this step, this IMR node sets ImrRepsonseA to the value of either “ACCEPT” or “REJECT”, based on which the workflow step can recognize that a response has been received.
If no response is required, then the waiting for a response can be eliminated by setting the value of “NORESPONSE” in the Targets field. In such a case, a successfully sent SMS will lead to the node termination with success.
Reference ID (ReferenceId) |
An ID of the gateway beyond which the message is to be sent. |
Target ID (TargetId) |
An ID of the template that is to be used as default. If it is NULL or the template cannot be found, then the SmsText field will be used directly for the message text. If the template is found, the $Parameters$ macro-code is replaced with the content of the SmsText field. In this case, the ##AC##, ##RC## and ##DL## macro-codes can be used in the template. For more information on macro-expansion, please refer to the Message module description. |
Max. period of time (TimeOut) |
A period of waiting for a response |
Reference number (Reference) |
A selection indicating which field is to be used. The value of 1,2,3 selects Sms1,2,3. No other values are allowed; it is a mandatory parameter. If the relevant field is not filled out, the script jumps to TargetOnTimeOut. |
Target values (Targets) |
If filled out as “NORESPONSE”, then the node does not wait for a response SMS and the node succeeds right after sending the message. |
Possible events¶
StepSucceeded, StepFailed, StepTimedOut, MessageSent
ClosePaging (Close paging)¶
This action command closes the paging that is associated with the workflow. It expects InstanceRefId to contain a reference to Paging, and this paging is brought to the closed status (the Activity field is set to “Closed”), and for all PagingMember members, whose participation has not been settled (their status is non-active - NotActive or Waiting for a response - Pending), the script sets the status of Canceled (Canceled).
This step has no other parameters.
Note: The step will not terminate the related workflows. If the step is not the last one in a script and it is necessary, then the Result step still needs to be used.
Possible events¶
StepSucceeded
DelayUntilPaging (Wait for paging to start)¶
This action command waits until the paging start time (Paging). It expects InstanceRefId to contain the Paging record. It ends as TargetOnSuccess, yet if the paging ends earlier (if it is not in the “Active” status), the step ends with TargetOnFailure.
The step has no other parameters.
Possible events¶
StepSucceeded, StepFailed
EtlLoad (Load ETL data)¶
This action command creates a ChangeRequest with the command of “EtlLoad” to load data from a pre-defined source of facts (the EtlFactSource template) to the OLAP cube (defined in EtlCube). If a form is associated with the WF, the node simultaneously generates a set of parameters based on the settings in Parameters. Apart from the fields of ChangeRequest.SubjectId and DataId and the JSON parameter structure in the Text field, the node also fills ChangeRequest.ReferenceId with the value of WorkflowInstanceId or InstanceRefId. The step ends with a success if the validations of the existence of EtlFactSource and EtlCube were valid, and ends with a failure if any of them failed.
Reference ID (ReferenceId) |
An ID of a rule used to load data from the EtlFactSourceId data source; once validated, the data is written in ChangeRequest.SubjectId |
Target ID (TargetId) |
An ID of the OLAP data cube to which the data from the source is to be placed (EtlCubeId); once validated, the data is written to ChangeRequest .DataId |
Parameters (Parameters) |
Names of data set fields (TargetColumn), the values of which will be used as the request parameters in the ChangeRequest.A text (JSON structure). The separating characters are commas or semicolons. The parameter sequence determines their rank in the request (and usually insertion in the SQL command). If the field is empty or the WF has no data set form associated, the request will have no parameters. Special parameters: “##WorkflowInstanceId##” – an ID of the running instance “##InstanceKey##” – a key related to the instance “##InstanceRefId##” – an ID related to the instance “##Result##” – the current value of the instance result field (Result) “##ScenarioResultId##” – an ID of the data set associated with the instance “##StartTime##” – the instance start time (local time) “##CurrentTime##” – the current local time at the moment of command execution “##None##” – no parameter Example 1: “MemberNumber” Example 2: “MemberNumber,##Result##” |
Target values (Targets) |
Settings that are to be used as a source for ChangeRequest.ReferenceId:
|
Possible events¶
StepSucceeded, StepFailed
EtlErase (Erase ETL data)¶
This action command creates a ChangeRequest with the command of “EtlErase” to erase formerly loaded data in the OLAP cube based on the defined reference, which will be specified in ChangeRequest.ReferenceId with a value originating from WorkflowInstanceId or InstanceRefId. There can be multiple imports with the given reference. The step always ends successfully.
Target values (Targets) |
Settings that are to be used as a source for ChangeRequest.ReferenceId:
|
Possible events¶
StepSucceeded
EtlExport (Export ETL data)¶
This action command creates a ChangeRequest with the command of “EtlExport” to export data including additional dimensions based on a pre-defined template (EtlExport) from OLAP. Besides the ChangeRequest.SubjectId field, it will also fill ChangeRequest.ReferenceId with a value originating from WorkflowInstanceId or InstanceRefId. The step will end successfully if all validations have been valid, or fail if any of the validations failed.
Target ID (TargetId) |
An ID of the EtlExportId export template that is to be used for export; once validated, the data will be written to ChangeRequest.SubjectId |
Target values (Targets) |
Settings that are to be used as a source for ChangeRequest.ReferenceId:
|
Reference number (Reference) |
A setting indicating whether, following data export that is performed directly as campaign import, the import is to be activated (which would start the handling of campaign communication):
|
Possible events¶
StepSucceeded, StepFailed
EtlForget (Forget information about ETL export)¶
This action command creates a ChangeRequest with the command of “EtlForget” to erase data on the export performed (in particular the “SNAPSHOT” column created in the OLAP cube) based on the defined reference, which will be specified in ChangeRequest.ReferenceId with a value originating from WorkflowInstanceId or InstanceRefId. There can be multiple exports with the given reference. The step always ends successfully.
Target values (Targets) |
Settings that are to be used as a source for ChangeRequest.ReferenceId:
|
Possible events¶
StepSucceeded
Workflow Triggers¶
Workflows are triggered based on either events in the system or direct entries made in the database (usually when customizing the system). Workflow triggers (ActionTrigger) are used to set what is to be started.
General trigger parameters¶
A trigger makes it possible to optionally execute actions, with suitable parameters submitted for each of the actions:
SQL command – This is to be entered in the ” SQL command text” section; it can execute any T-SQL command, such as UPDATE or EXEC
Workflow – Starts a defined asynchronous workflow
Depending on the trigger type, the calendar can be respected, ignored or used in a special manner. If the calendar is respected and an event is triggered outside the calendar validity period, the TriggerSkipped event is recorded in the WorkflowEventLog.
When the calendar is respect as normal, the calendar validity is determined according to the Calendar Mode (local time is used for the evaluation):
Empty – Valid for all times
- Weekly – Valid for a weekly period; the first valid day in the week is taken from the “From” date; only the time period within the valid day is considered that starts at the “From” time and ends at the “To” timeExample: Definition of Weekly: from 23.1.2017 8:00:00 to 27.1.2017 17:00:00 means that it is valid for all weekdays (from Monday to Friday) from 8am to 5pm (23 Jan 2017 was Monday, 27 Jan 2017 was Friday); it is not valid at night from 5pm to 8am and on all weekend days
Weekly (inverse) – The same definition was with “Weekly”, yet inverted (i.e. where the Weekly rule applies, the Weekly (inverse) rule does not apply)
Yearly – Valid yearly for a period “From” to “To”; the date is considered excluding the year and the exact time (the year is ignored)
Single – Valid for a one-off period “From” to “To”; the exact date and time (including year) are considered
Manual (Manual trigger)¶
This trigger type is used to for triggering using an SQL script or using a special WP “Manual action”, which makes it possible to launch an instance for every marked record from the associated data table (grid):
Settings:
You can choose from “Manual” triggers only; the WP needs to be connected with the data table:
The data table must contain a column called RecordId, which is of the GUID type:
The following parameters are submitted when the trigger is called:
SQL elements - @RecordId, @AgentId, @ActionTriggerId and @ReferenceKey
WF elements - RecordId is saved as InstanceRefId, ReferenceKey as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the triggering agent’s GUID in the ReferenceData field and ActionTriggerId in ReferenceId.
The interval and calendar do not play any role in triggering. The trigger does not set the fields of LastRunUtc and LastWorkflowInstanceId.
Schedule (Time plan)¶
This type is triggered at a set time. The time is set using the calendar and the “From” time. Days are set according to the Calendar Mode:
Weekly – Triggered every day at the time indicated in the “From” field on the weekdays set in the fields “From” and “To”
Weekly (inverse) – Triggered every day at the time indicated in the “From” field except on the weekdays set in the fields “From” and “To”
Yearly – Triggered every day at the time specified in the “From” field every year on the weekdays set in the fields “From” and “To”
Single – Triggered every day at the time specified in the “From” field
The following parameters are submitted when the trigger is called:
SQL elements - @ActionTriggerId, @ReferenceKey (the ReferenceKey trigger value)
WF elements - ReferenceKey as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the ActionTriggerId value in ReferenceId.
The trigger sets the LastRunUtc field to the time of the next planned start. The trigger does not check whether the previous instance is running.
When you save the settings in the administration interface with the Reset option checked, the LastRunUtc field will be deleted, which causes the trigger to be scheduled for the earliest possible time; this is practical when the trigger time changes. It is recommended to set the “To” time to a time at least one hour after the planned start time specified in the “From” field.
PeriodMonth (Monthly period)¶
This type is triggered periodically, once in N months (the number of months is determined by the Interval field) on a day of the month specified in the field (Shift – a positive shift – from the month start [1 means 1st]; negative shift – from the month end [-1 means 31st , 30th or 28th or 29th of the month] – The shift should not be greater than the number of days in the month) at the set time (Trigger time). The triggering can be limited using the calendar; if the periodical occurrence falls outside a valid calendar period, the trigger is skipped (with TriggerSkipped being logged). Interval not filled out = 1, Shift not filled out = 1, Trigger time not filled out = 00:40.
The following parameters are submitted when the trigger is called:
SQL elements - @ActionTriggerId and @ReferenceKey (the ReferenceKey trigger value)
WF elements - ReferenceKey as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the ActionTriggerId value in ReferenceId.
The trigger sets the LastRunUtc field to the time of the next planned trigger. The trigger does not check whether the previous instance is running.
When you save the settings in the administration interface with the Reset option checked, the LastRunUtc field will be deleted, which causes the trigger to be scheduled for the earliest possible time according to the scheme. The planning parameters (Interval, Offset) are taken into consideration always during the next scheduling. The calendar is checked at the time when the trigger is called. If it is necessary to trigger a sequence of repetitions from a specific date, this can be achieved by using the calendar in the Single mode and setting a start date.
Algorithm to find the first trigger date (the time considered is always the Trigger time):
Take the current month and select a day based on the Shift
If it is in the past, take the immediately following month and select a day based on the Shift
If the day falls within the valid calendar period, it is used as the first trigger time (LastRunUtc). †
Otherwise, the first possible valid calendar period is evaluated
If it cannot be identified, the next trigger time will be set in ten years (LastRunUtc), which effectively turns it off. †
Otherwise, the month is taken from the identified period and a day is selected based on the Shift.
This date is used as the trigger time (LastRunUtc) regardless of the calendar validity. It is not recommended that the calendar begins in the middle of the month and at a time different from 00:00. †
PeriodWeek (Weekly period)¶
This type is triggered periodically, once in N weeks (the number of weeks is determined by the Interval field) on a day of the week specified in the field (Shift – a positive shift [1 means Monday], the shift should not be greater than 7) at the set time (Trigger time). The triggering can be limited using the calendar; if the periodical occurrence falls outside a valid calendar period, the trigger is skipped (with TriggerSkipped being logged). Interval not filled out = 1, Shift not filled out = 1, Trigger time not filled out = 00:40.
The following parameters are submitted when the trigger is called:
SQL elements - @ActionTriggerId and @ReferenceKey (the ReferenceKey trigger value)
WF elements - ReferenceKey as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the ActionTriggerId value in ReferenceId.
The trigger sets the LastRunUtc field to the time of the next planned trigger. The trigger does not check whether the previous instance is running.
When you save the settings in the administration interface with the Reset option checked, the LastRunUtc field will be deleted, which causes the trigger to be scheduled for the earliest possible time according to the scheme. The planning parameters (Interval, Offset) are taken into consideration always during the next scheduling. The calendar is checked at the time when the trigger is called. If it is necessary to trigger a sequence of repetitions from a specific date, this can be achieved by using the calendar in the Single mode and setting a start date.
Algorithm to find the first trigger date (the time considered is always the Trigger time):
Take the current week and select a day of the week based on the Shift
If it is in the past, take the immediately following week and select a day based on the Shift
If the day falls within the valid calendar period, it is used as the first trigger time (LastRunUtc). †
Otherwise, the first possible valid calendar period is evaluated
If it cannot be identified, the next trigger time will be set in ten years (LastRunUtc), which effectively turns it off. †
Otherwise, the week (Monday) is taken from the identified period and a day is selected based on the Shift.
This date is used as the trigger time (LastRunUtc) regardless of the calendar validity. It is not recommended that the calendar begins in the middle of the week and at a time different from 00:00. †
PeriodDay (Daily period)¶
This type is triggered periodically, once in N days (the number of days is determined by the Interval field, Shift is disregarded). The triggering can be limited using the calendar; if the periodical occurrence falls outside a valid calendar period, the trigger is skipped (with TriggerSkipped being logged). Interval not filled out = 1, Trigger time not filled out = 00:40.
The following parameters are submitted when the trigger is called:
SQL elements - @ActionTriggerId and @ReferenceKey (the ReferenceKey trigger value)
WF elements - ReferenceKey as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the ActionTriggerId value in ReferenceId.
The trigger sets the LastRunUtc field to the time of the next planned trigger. The trigger does not check whether the previous instance is running.
When you save the settings in the administration interface with the Reset option checked, the LastRunUtc field will be deleted, which causes the trigger to be scheduled for the earliest possible time according to the scheme. The planning parameters (Interval, Offset) are taken into consideration always during the next scheduling. The calendar is checked at the time when the trigger is called. If it is necessary to trigger a sequence of repetitions from a specific date, this can be achieved by using the calendar in the Single mode and setting a start date.
Algorithm to find the first trigger date (the time considered is always the Trigger time):
Take the current day
If the day falls within the valid calendar period, it is used as the first trigger time (LastRunUtc). †
Otherwise, the first possible valid calendar period is evaluated
If it cannot be identified, the next trigger time will be set in ten years (LastRunUtc), which effectively turns it off. †
This date is used as the trigger time (LastRunUtc). It is not recommended that the calendar begins in the middle of the day. †
Interval (Regular minute intervals)¶
This type is triggered at regular intervals during the calendar active periods (if the calendar is used).
The Interval parameter indicates the triggering frequency in minutes. The shortest possible interval is thus one minute. Considering the nature of the asynchronous run, the actual trigger interval between two instances can vary by up to 59 seconds.
The following parameters are submitted when the trigger is called:
SQL elements - @ActionTriggerId and @ReferenceKey (the ReferenceKey trigger value)
WF elements - ReferenceKey as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the ActionTriggerId value in ReferenceId.
The trigger sets the LastRunUtc field to the time of the next planned trigger. The trigger does not check whether the previous instance is running.
When you save the settings in the administration interface with the Reset option checked, the LastRunUtc field will be deleted, which causes the trigger to be scheduled for the earliest possible time – this is desirable when the trigger time changes. If the calendar is used, it is recommended to set the time window to the duration of one interval less a few seconds.
ServiceStarted (Service started)¶
This type is triggered when the relevant system service is ready to run, provided that the service name equals the parameter (ReferenceKey).
Note: If the system is configured as a duplex system, the trigger on the Slave system will be released and switch from the waiting status to actively running.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (empty), @ActionTriggerId, @ReferenceData (DuplexMode parameter value from the service configuration file: None, Master, Slave) and @ReferenceKey (service name)
WF elements - InstanceRefId is empty, the service name is identical to InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the DuplexMode parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value.
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the same trigger will be activated for all services; in such a case, there can be just one trigger of this type defined.
Possible values for ReferenceKey:
iCC.ServiceSync
iCC.ServiceAsync
iCC.ServiceBulk
iCC.ReactClient
Empty (any value)
AcceptData (REST data accepted)¶
This type is triggered when the REST request of type “AcceptData” comes from a user with RestRpc permission AllowFull, provided that the service name equals the parameter (ReferenceKey).
The following parameters are submitted when the trigger is called:
SQL elements - @Id (ChangeRequestId created by AcceptData), @ActionTriggerId, @ReferenceData (not used) and @ReferenceKey (one of AcceptDataPost, AcceptDataPut, AcceptDataGet, AcceptDataDelete).
WF elements - InstanceRefId is ChangeRequestId created by AcceptData, the service name is identical to InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance; the ReferenceId field contains the ActionTriggerId value.
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the same trigger will be activated for all services; in such a case, there can be just one trigger of this type defined.
Possible values for ReferenceKey:
AcceptDataPost
AcceptDataPut
AcceptDataGet
AcceptDataDelete
Empty (any value)
InboundCallPhaseChanged (Inbound call phase changed)¶
This type is triggered for every inbound call (InboundCall) if the target phase (the CallPhase field) to which the call is changing equals the parameter (ReferenceKey) value.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (InboundCallId), @ActionTriggerId, @ReferenceData (call type in CallType) and @ReferenceKey (call phase when triggered, which may differ from the call phase when executing)
WF elements - InboundCallId is saved as InstanceRefId, CallPhase as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the CallType parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey is never used.
Possible values for ReferenceKey:
Pilot
AnnouncementA
AnnouncementB
AnnouncementW
IvrScriptA
IvrScriptB
IvrScriptW
Enqueue
WaitingQueue
DispatchQueue
AgentRingFirst
AgentRingNext
AgentRingMissed
ManualDispatch
AgentTalk
HangupAgent
HangupCaller
TerminatedA
TerminatedB
TerminatedW
TransferredA
TransferredB
TransferredW
InboundCallResultChanged (Inbound call result changed)¶
This type is triggered for every inbound call (InboundCall) if the call result (the CallResult field) to which the call is changing equals the parameter (ReferenceKey) value.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (InboundCallId), @ActionTriggerId, @ReferenceData (call type in CallType) and @ReferenceKey (call result when triggered, which may differ from the call result upon execution for the Active result)
WF elements - InboundCallId is saved as InstanceRefId, CallResult as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the CallType parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the trigger activates for all CallResult values; in such a case, there can be just one trigger of this type defined.
Possible values for ReferenceKey:
Active
Served
Lost
Empty (any value)
OutboundCallPhaseChanged (Outbound call phase changed)¶
This type is triggered for every outbound call (OutboundCall) if the target phase (the CallPhase field) to which the call is changing equals the parameter (ReferenceKey) value.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (OutboundCallId), @ActionTriggerId, @ReferenceData (call type in CallType) and @ReferenceKey (call phase when triggered, which may differ from the call phase when executing)
WF elements - OutboundCallId is saved as InstanceRefId, CallPhase as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the CallType parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey is never used.
Possible values for ReferenceKey:
New
Enqueue
EnqueueNoTime
EnqueueTimedOut
AgentOfferFirst
AgentOfferMissed
AgentOfferNext
AgentDialing
AgentTalk
AutoDial
IvrScriptA
TerminatedA
HangupAgent
HangupCalled
WaitForResult
OutboundCallResultChanged (Outbound call result changed)¶
This type is triggered for every outbound call (OutboundCall) if the call result (the CallResult field) to which the call is changing equals the parameter (ReferenceKey) value. It will be triggered for the Prepared value even when a new call is initiated, yet not when calls are imported (OutboundListImport) using the tools available in WebAdmin and neither when scheduled for calling (Scheduled) using the WebAdmin tool, neither when paused (Paused) using the WebAdmin tool nor when scheduling (Scheduled) or canceling (Canceled) campaign calls (OutboundList) using the WebAdmin tools.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (OutboundCallId), @ActionTriggerId, @ReferenceData (call type in CallType) and @ReferenceKey (call result when triggered, which may differ from the call result upon execution for the Active result)
WF elements - OutboundCallId is saved as InstanceRefId, CallResult as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the CallType parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the trigger activates for all CallResult values; in such a case, there can be just one trigger of this type defined.
Possible values for ReferenceKey:
Prepared
Scheduled
Paused
Active
Neglected
Canceled
Completed
Failed
Busy
NoAnswer
TalkError
ToContinue
NoResult
Empty (any value)
MessagePhaseChanged (Message phase changed)¶
This type is triggered for every message (E-mail, SMS, Fax, Task, Note) if the target phase (the MessagePhase field) to which the message is changing equals the parameter (ReferenceKey) value.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (MessageId), @ActionTriggerId, @ReferenceData (message type in MessageType) and @ReferenceKey (message phase when triggered, which may differ from the message phase when executing)
WF elements - MessageId is saved as InstanceRefId, MessagePhase as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the MessageType parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey is never used.
Possible values for ReferenceKey:
Receiving
Received
Read
Accepted
Answering
Closed
Terminate
Draft
Scheduled
Failed
Sent
Confirmed
Canceled
New
Open
Hold
Wait
ChatPhaseChanged (Chat phase changed)¶
This type is triggered for every chat (BusinessIM, SocialIM, WebIM) if the target phase (the ChatPhase field) to which the chat is changing equals the parameter (ReferenceKey) value.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (ChatId), @ActionTriggerId, @ReferenceData (message type in ChatType) and @ReferenceKey (message phase when triggered, which may differ from the message phase when executing)
WF elements - ChatId is saved as InstanceRefId, ChatPhase as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the ChatType parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey is never used.
Possible values for ReferenceKey:
New (start for outgoing chats)
Pilot (start for incoming chats)
Enqueue
Waiting
AlertFirst
AlertNext
AlertMissed
Talk
Transferring
ClosedAgent
ClosedExtApp
ClosedInactive
IssuePhaseChanged (Issue phase changed)¶
This type is triggered for every issue (Issue) if the target phase (the PhaseId field) to which the issue is changing equals the parameter (ReferenceKey – GUID in the hyphen format) value.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (IssueId), @ActionTriggerId, @ReferenceData (issue activity in the Activity field) and @ReferenceKey (issue phase when triggered, which may differ from the issue phase when executing; a text-expressed GUID from the issue phase table)
WF elements - IssueId is saved as InstanceRefId, PhaseId (GUID in the hyphen format) as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the Issue Activity parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey is never used.
An example of the ReferenceKey value (not case sensitive):
f01c3a31-2ca4-4139-a1e3-1b9bbb2441f9
IssueAssigned (Issue assigned)¶
This type is triggered for every issue (Issue) if the issue is assigned to an agent (the AgentId field). If necessary, the trigger can be limited just to a situation when the agent is a member of the team (TeamName) that is stated in ReferenceKey.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (IssueId), @ActionTriggerId, @ReferenceData (the assigned agent’s GUID at the time of execution in a hyphen format) and @ReferenceKey (the assigned agent’s team when executing)
WF elements - IssueId is saved as InstanceRefId, TeamName as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains AgentId (the agent’s GUID in the hyphen format) parameter value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the trigger is activated for all TeamName values; in this case, there can be just one trigger of this type defined.
An example of the ReferenceKey value (not case sensitive):
BackOffice
Empty (any value)
IssueUnassigned (Issue unassigned)¶
This type is triggered for every issue (Issue) if the issue is returned, i.e. it is no longer assigned to an agent (the AgentId field is NULL).
The following parameters are submitted when the trigger is called:
SQL elements - @Id (IssueId), @ActionTriggerId, @ReferenceData (GUID of the originally assigned agent at the time of triggering in the hyphen format) and @ReferenceKey (the team of the originally assigned agent when triggered)
WF elements - IssueId is saved as InstanceRefId, the original TeamName value as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the original AgentId value (agent GUID in the hyphen format) in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type in the system and it does not use ReferenceKey, which must therefore be empty.
IssueSaved (Issue saved)¶
This type is triggered for every issue (Issue) if the issue is saved in the editor (use the Save button when editing; it is called for the REST operations and CSV imports), and it is also triggered when the issue is initially created. This applies to changes in Topic/SubTopic, DisplayName, BodyHtml, Phase, IssueKey. It may also be exceptionally called when there was actually no change in the Issue fields (e.g. there was just a change in the form).
The following parameters are submitted when the trigger is called:
SQL elements - @Id (IssueId), @ActionTriggerId, @ReferenceData (if the issue is created, it contains “true”, while when it is simply saved, the value is “false”). @ReferenceKey is not used.
WF elements - IssueId is saved as InstanceRefId, InstanceKey is not used, and the Triggered (90) event is associated simultaneously with the WF instance, which in the ReferenceData field contains “true” if the issue is created or “false” when simply saving; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type in the system and it does not use ReferenceKey, which must therefore be empty.
ContactSaved (Contact saved)¶
This type is triggered for every contact (Contact) if the contact model (the Model field) equals the ReferenceKey value (or ReferenceKey is empty) and it concerns editor saving (when editing – the Save or Delete button; it is not called for the REST operations and CSV imports)
The following parameters are submitted when the trigger is called:
SQL elements - @Id (ContactId), @ActionTriggerId, @ReferenceData (the contact Deleted status – the value is “true” or “false”) and @ReferenceKey (contact Model).
WF elements - ContactId is saved as InstanceRefId, Model as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the Deleted form value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the trigger is applied regardless of Model.
An example of a ReferenceKey value (not case sensitive):
Person
FormSaved (Form data saved)¶
This type is triggered for every form (ScenarioResult) if the scenario (the ScenarioId field) equals the parameter (ReferenceKey – GUID in the hyphen format) value and it concerns form saving (within IVR; when editing – the Save button; it needs not be called by transferring to another page and when saving due to DDN cascading; it is not called for the REST operations and CSV imports)
The following parameters are submitted when the trigger is called:
SQL elements - @Id (ScenarioResultId), @ActionTriggerId, @ReferenceData (form activity in the Activity field) and @ReferenceKey (form scenario – a text-expressed GUID).
WF elements - ScenarioResultId is saved as InstanceRefId, ScenarioId (GUID in the hyphen format) as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the Deleted form value in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the trigger is applied regardless of Scenario.
An example of a ReferenceKey value (not case sensitive):
f01c3a31-2ca4-4139-a1e3-1b9bbb2441f9
AgentGoingReady (Agent is going to be ready)¶
This type is triggered for every agent (Agent) if their activity (the Activity field) is to be changed to the Ready status (Ready) and, at the same time, the agent is from a pre-defined team (ReferenceKey – a name of the team to which the trigger applies; if it is NULL, it is triggered for all agents in the installation).
Note: The trigger is activated just before the status changes, i.e. the DB will at that moment still show the previous status for the given agent. The SQL part is triggered synchronously; therefore, it should not delay the action execution since it would delay the CC agent status change. The WF part runs asynchronously and it is likely that it will take place only after the actual status change in the database.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (AgentId), @ActionTriggerId, @ReferenceData (an ID of the status to which the agent will be changing – GUID in the hyphen format from the StatusId table) and @ReferenceKey (the agent’s team)
WF elements - AgentId is saved as InstanceRefId, StatusId (GUID in the hyphen format) as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the agent’s team in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the trigger is applied regardless of the team.
An example of a ReferenceKey value (not case sensitive):
CustCarePHA
AgentStatusChanged (Agent status changed)¶
This type is triggered for every agent (Agent) after every status change, provided that the agent is from the pre-defined team (ReferenceKey – a name of the team to which the trigger applies; if it is NULL, it is triggered for all agents in the installation).
Note: The trigger is activated after every change, i.e. the DB will at that moment already show the target status for the given agent. The SQL part is triggered synchronously in a single thread dedicated to status changes; therefore, it should not delay the action execution since it would delay the CC agent status change. The WF part runs asynchronously.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (AgentId), @ActionTriggerId, @ReferenceData (an ID of the status to which the agent has changed – GUID in the hyphen format from the StatusId table) and @ReferenceKey (the agent’s team)
WF elements - AgentId is saved as InstanceRefId, StatusId (GUID in the hyphen format) as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the agent’s team in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type for each ReferenceKey; if more of them are defined, the system will randomly choose one of them (which is not desirable). An empty ReferenceKey means that the trigger is applied regardless of the team.
An example of a ReferenceKey value (not case sensitive):
CustCarePHA
AgentCreated (Agent created)¶
This type is triggered to create an agent (Agent) in the database, whether in the administration environment or using IDM.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (AgentId), @ActionTriggerId, @ReferenceData contains the operation source (WebAdmin or IDM)
WF elements - AgentId is saved as InstanceRefId, StatusId (GUID in the hyphen format) as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the operation source (WebAdmin or IDM) in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type in the system; if more of them are defined, the system will randomly choose one of them (which is not desirable).
AgentReactivated (Agent reactivated)¶
This type is triggered when agent deletion is canceled in the database (the Agent Deleted field is zeroed) or it is changed from the template back to the agent (the Agent Template field is zeroed), whether in the administration environment or using IDM.
Note: The agent is reactivated only if Deleted=false, Template=false.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (AgentId), @ActionTriggerId, @ReferenceData contains the operation source (WebAdmin or IDM)
WF elements - AgentId is saved as InstanceRefId, StatusId (GUID in the hyphen format) as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the operation source (WebAdmin or IDM) in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type in the system; if more of them are defined, the system will randomly choose one of them (which is not desirable).
AgentDeleted (Agent deleted)¶
This type is triggered when agent deletion is set in the database (the Agent Deleted field) or it is changed from the agent back to the template (the Template field set), whether in the administration environment or using IDM.
The following parameters are submitted when the trigger is called:
SQL elements - @Id (AgentId), @ActionTriggerId, @ReferenceData contains the operation source (WebAdmin or IDM)
WF elements - AgentId is saved as InstanceRefId, StatusId (GUID in the hyphen format) as InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the operation source (WebAdmin or IDM) in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type in the system; if more of them are defined, the system will randomly choose one of them (which is not desirable).
AgentCalcOnStatus (Calculation on agent status change)¶
This type is triggered for every agent (Agent) after every status change for the just closed event of the AgentStatus type. The trigger performs an interval calculation – it removes ineffective intervals from the scope from the beginning of the closed event to the current time (during its duration). To obtain blocked intervals, the SQL part is triggered first. It must return a set of event records that are to be excluded from the overall interval; they are acquired in two columns. The first column is the event time in UTC whereas the other column represents an added (a positive integer) or removed (a negative integer) block. Subsequently, the trigger excludes the blocked intervals and receives a set of non-blocked intervals. Depending on the Offset parameter, it then creates a set of events of the ReferenceKey type (if there are no non-blocked intervals, it creates none), always with the relevant start of TimeUtc, TimeLocal and Duration (for Offset NULL or 0), or it sums up the duration of non-blocked intervals and creates a single event of the ReferenceKey type (it always creates an event if there are no non-blocked intervals; the duration will be 0) with the start at TimeUtc, TimeLocal same as the referenced event, and Duration based on the sum (for Offset 1). The events created always have AgentId filled out according to the original event, TeamName according to the original event, WorkplaceId according to the original event, ReferenceId is the original event ID, ReferenceData is the original event Activity, and ResultData is ActionTriggerId that performed the calculation. The Actor will always be “Trigger”. ActorId will be empty.
Subsequently, if a workflow is set, it is triggered, with InstanceRefId being the original event ID, InstanceKey being ReferenceKey or names of newly created events.
Note: The trigger is activated after the status changes, i.e. the DB already shows the agent’s target status and the referenced event is already closed, yet it is activated still before the AgentStatusChange trigger. The SQL part is triggered asynchronously in a new thread; nevertheless, it should not excessively delay the event execution. The WF part runs asynchronously afterwards.
The following parameters are submitted when the SQL part of the trigger is called:
@AgentId (AgentId), @Id (AgentEventId of the referenced event), @StartUtc (UTC time when the referenced event starts – inclusive, i.e. >=), @EndUtc (UTC time when the referenced event ends – exclusive, i.e. <), @ActionTriggerId, @StatusId (the agent’s status with the referenced event), @Activity (the agent’s activity with the referenced event), @Utc2Local (local time shift compared to the UTC time in seconds), @TodayUtc (local midnight in the UTC time – this relates to event resets performed at night).
The following parameters are submitted when the WF part is called:
AgentEventId of the original referenced closed event is saved as InstanceRefId, ReferenceKey, or a name of the created secondary events, is saved in InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the number of created secondary events in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value.
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type in the system; if more of them are defined, the system will execute the triggers simultaneously and asynchronously in an unspecific order.
An example of SqlCmd returning intervals to be excluded (IC and OC conversation times):
select TimeUtc, case when EventType IN ('AgentAnswer','AgentAccepted') then 1 else -1 end as Offset from CallEvent
where AgentId=@AgentId AND EventType IN ('AgentAnswer','HangupAgent','HangupCaller', 'AgentAccepted', 'HangupCalled') AND
TimeUtc between DATEADD(hour, -1, @StartUtc) AND @EndUtc
Called for an event with TimeUtc = 2019-03-08 00:49:24.027 at 2019-03-08 00:56:44.220
Data returned by the trigger query; the last record corresponds to the current call:
TimeUtc |
Offset |
|---|---|
2019-03-07 23:55:43.307 |
1 |
2019-03-07 23:55:53.787 |
-1 |
2019-03-07 23:58:31.793 |
1 |
2019-03-07 23:58:44.247 |
-1 |
2019-03-08 00:08:53.060 |
1 |
2019-03-08 00:47:35.053 |
1 |
2019-03-08 00:47:42.510 |
-1 |
2019-03-08 00:56:38.203 |
1 |
Note: The set of events returned by the query can begin before @StartUtc and end after @EndUtc, and it need not be sorted. When processing the data, the trigger will sort it and remove any excess data or use it to establish the initial status.
Generated events:
AgentCalcOnCorrelation (Calculation on agent correlation change)¶
This type is triggered for every agent (Agent) after every correlation change for the just closed event of the AgentCorrelation type. The trigger performs an interval calculation – it removes ineffective intervals from the scope from the beginning of the closed event to the current time (during its duration). To obtain blocked intervals, the SQL part is triggered first. It must return a set of event records that are to be excluded from the overall interval; they are acquired in two columns. The first column is the event time in UTC whereas the other column represents an added (a positive integer) or removed (a negative integer) block. Subsequently, the trigger excludes the blocked intervals and receives a set of non-blocked intervals. Depending on the Offset parameter, it then creates a set of events of the ReferenceKey type (if there are no non-blocked intervals, it creates none), always with the relevant start of TimeUtc, TimeLocal and Duration (for Offset NULL or 0), or it sums up the duration of non-blocked intervals and creates a single event of the ReferenceKey type (it always creates an event if there are no non-blocked intervals; the duration will be 0) with the start at TimeUtc, TimeLocal same as the referenced event, and Duration based on the sum (for Offset 1). The events created always have AgentId filled out according to the original event, TeamName according to the original event, WorkplaceId according to the original event, ReferenceId is the original event ID, ReferenceData is the original event Activity, and ResultData is ActionTriggerId that performed the calculation. The Actor will always be “Trigger”. ActorId will be empty.
Subsequently, if a workflow is set, it is triggered, with InstanceRefId being the original event ID, InstanceKey being ReferenceKey or names of newly created events.
Note: The trigger is activated after the correlation changes, i.e. the DB already shows the agent’s target correlation and the referenced event is already closed. The SQL part is triggered asynchronously in a new thread; nevertheless, it should not excessively delay the event execution. The WF part runs asynchronously afterwards.
The following parameters are submitted when the SQL part of the trigger is called:
@AgentId (AgentId), @Id (AgentEventId of the referenced event), @StartUtc (UTC time when the referenced event starts – inclusive, i.e. >= ), @EndUtc (UTC time when the referenced event ends – exclusive, i.e. < ), @ActionTriggerId, @Correlation (the agent’s correlation with the referenced event), @Utc2Local (local time shift compared to the UTC time in seconds).
The following parameters are submitted when the WF part is called:
AgentEventId of the original referenced closed event is saved as InstanceRefId, ReferenceKey, or a name of the created secondary events, is saved in InstanceKey, and the Triggered (90) event is associated simultaneously with the WF instance, which contains the number of created secondary events in the ReferenceData field; the ReferenceId field contains the ActionTriggerId value.
The TimeMode calendar of the trigger is respected. The Interval is disregarded when triggering. The trigger sets neither the LastRunUtc field nor the LastWorkflowInstanceId field.
There may be just one trigger of this type in the system; if more of them are defined, the system will execute the triggers simultaneously and asynchronously in an unspecific order.
The trigger works similarly to AgentCalcOnStatus and can be used, for example, to calculate overtime work without the Break status.
Note: The set of events returned by the query can begin before @StartUtc and end after @EndUtc, and it need not be sorted. When processing the data, the trigger will sort it and remove any excess data or use it to establish the initial status.