The Panel platform workflow module allows you to create workflows that perform actions in response to event triggers. Workflows are configured in Panel Settings. Every time an object is saved to the Panel API, it is evaluated against workflow triggers. Once a workflow is triggered it is entered into the workflow queue. Every 60 seconds, the Panel Service processes workflows that are pending in the queue.
When Panel Service executes workflows, the queue is processed in order, and each step is processed sequentially. At this version, within a single Panel Service instance, there is no parallel execution of workflow steps. This requires that some thought be given prior to creating long-running workflow steps.
Workflows can be triggered by any data being saved to Panel platform. Common examples are a failed health check, unusual run history results, or the changing state of a CS or MV object. Workflows are able to perform tasks like send an email, run programs and scripts, or generate and email a report.
The results of workflow execution are displayed in the History viewer, and are searchable.
Workflow History records have RecordOf set to "Process Workflows", and Argument set to the workflow name that is configured in settings. This makes it possible to chart the frequency of individual workflows over time.
Workflow Triggered: 80 Workflow Completed: 81 Workflow Step Processed: 82 Workflow Inspected: 83 Workflow Error: 84
Unlike schedules, workflows do not have their own settings section. Instead, you create a Workflow Provider instance in the Settings/Providers section. This allows you to group related workflows together in different providers so you can download and upload settings in batches.
Individual workflow configurations can be added, deleted, duplicated, expanded, collapsed, and re-ordered. The controls for these actions are similar to Schedules.
As with schedules each workflow can be assigned to a preferred scheduler for processing.
When you create a new workflow, you must configure the Trigger. The trigger consists of an Object Type and a Rule.
Trigger Object Type
The Object Type indicates the type of object for which this workflow can be considered. The list of possible object types is dynamically generated depending on what modules are installed.
To see information about what kinds of objects can be triggered and what properties that have, click on the one of the Rule Help question marks, and expand the Object Properties section.
Within the scope of a Context Type, the workflow engine uses the Rule Engine to evaluate the trigger rule. If the trigger rule returns true, then the workflow is invoked and a Workflow Record is added to the processing queue. Most workflow triggers inspect Object Properties, and use Functions to transform and evaluate them.
The Aggregate functions are particularly helpful for writing workflow triggers.
In particular, the Count function can be used to trigger a workflow after an event has crossed a threshold, and the Once function can be used to trigger a workflow only the first time a particular criteria or threshold is crossed in a time-period.
After configuring the trigger, you add steps to the workflow. The available steps depend on what modules are installed.
Although you can drag-and-drop to re-order steps in the interface, this is purely cosmetic. The order of execution for steps depends on the configuration of each step. Each step type defines a "Next Step" attribute, but it is also possible to influence step order using the Link function.
All workflow steps have a required Name setting, which is used for step references.
Rule Engine in Steps
Most text fields in Workflow steps allow dynamic template values to be inserted with the Rule engine. If a rule can be inserted, there will be a help icon in the right side of the text box. Rules inside workflow steps should be enclosed in square braces.
If you want to add literal square braces to the text of a workflow step, you must escape the open brace with a backslash ('\') character.
Text in \[literal square braces]
The Link function provides a way to queue up a workflow step by clicking on a link in an email, or by invoking an HTTP web request from a script. This allows approval workflows to be created. When the Link function is evaluated by the Rule Engine it generates a URL with a ciphered code that enables the Workflow engine to find an existing Workflow Record, set the next step, and add it back to the processing queue. The link function takes three arguments:
Link(NextStep, ExpiresAfter, ExpiredNextStep)
- NextStep: The string name of the step to be queued up
- ExpiresAfter: A time-span formatted string indicating how long the link remains valid
- ExiredNextStep (opt.): The string name of a step to execute if the link expires without being activated
Link("Execute Script", "7.00:00:00", "Escalate Manager")
Workflow Step Types
See Provider documentation for additional step types.
Sends an email to the designated recipient (requires that Email SMTP settings be populated).
- Recipient: Email address of message recipient — supports Rule Engine value handling.
- Subject: Email subject — supports Rule Engine value handling.
- Message: Email message content. Note that emails are sent as plain-text messages by default — supports Rule Engine value handling.
- Send As HTML: Whether the email message body should be sent with HTML formatting enabled.
- Next: Step to execute after sending the email.
Runs a PowerShell script, either locally or against the designated PS Remoting environment.
- Next: Step to run after executing the script.
- Use PS Remoting: decides whether to examine connection settings or simply run locally.
- Script: Required, the PowerShell script to run — supports Rule Engine value handling.
- Host: Host name if using PS Remoting
- User: User name for PS Remoting
- Password: Password for PS Remoting login. This may be overridden by the Panel:Password app setting.
- Auth Mechanism: PowerShell Auth Mechanism enumeration value.
- URI: sub-path combined with Host and protocol to create the connection URL.
- Schema URI: URI for PowerShell command schema. The default PowerShell schema is: http://schemas.microsoft.com/powershell/Microsoft.PowerShell and the default Exchange 2013 schema is: http://schemas.microsoft.com/powershell/Microsoft.Exchange
- Use SSL: whether to use http: or https: for remoting
- Port: Default PowerShell http: port is 5985. Default PowerShell https: port is 5986.
- Operation Timeout Seconds: Number of seconds to wait for response from a command before timing out. Defaults to 240 seconds (4 minutes).
- Max Redirect Count: Number of times to allow redirection from the PowerShell URL. Defaults to 3 redirects.
Runs an arbitrary program or script on the local server (local to SoftwareIDM Panel Service).
- Next: Step to run after the program terminates.
- Program: The program or script to execute. If it's on the PATH environment, the name is sufficient, otherwise the full file path is required.
- Arguments: The argument string to pass to the program — Supports Rule Engine value handling.
Starts, Stops, or Restarts a Windows service on either the local or a remote server. Note: the Panel Service service accounts must have permissions to control the designated services.
- Next: Step to run after performing the service task.
- Service: Name of the service to modify.
- Operation: Whether to Start, Stop, or Restart the service.
- Server: host name of the server the service is on.
- Wait for Status: Whether to wait for the service operation to complete before continuing on to the next step or workflow.
Writes a message to the Windows Event Log. The log written to depends on the Event Source identifier. By default, events are written to the "SoftwareIDM Panel Service" source in the Application event log.
- Next: Step to run after writing to the event log.
- Log Level: Whether to write an Information, Warning, or Error message.
- Event Source: Identifier of the Event Log Source to write to. Event Sources may be created using Regedit.
- Message: Content to write to the log — supports Rule Engine value handling.
Table of Contents
- Version 3.3.6 Release June 7, 2017
- Version 3.3 Release May 2, 2017
- Version 3.1 Release Nov 17, 2016
- Version 3.0 Release May 31, 2016
- Version 2.5 Release April 22, 2016
- Version 2.4 Release January 6, 2016
- Version 2.3 Release September 23, 2015
- Version 2.1 Release April 3, 2015
- Version 2.0.2 Limited Release March 11, 2015
- Version 1.4 Released August 12, 2014
- Workflow Module
- Azure Module
- Configuring Claims Authentication
- Creating a Custom Extension
- Rule Functions