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. 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 history supports several specific counters which may be used for history filtering and charting:
- Workflow Triggered
- Workflow Completed
- Workflow Step Processed
- Workflow Inspected
- Workflow Error
Workflows do not have their own settings section. Instead, like with health checks 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.
Each workflow can be assigned to a preferred server 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.
In rare cases you may want to trigger multiple workflows from a single object being saved. For example, you might want to record a separate help desk ticket from every run error.
In this scenario you can define a Map Rule. If a Map rule is defined a separate workflow will be created for each item in the returned list.
After configuring a trigger you add steps to the workflow. Available steps may depend on modules installed and licensing steps.
When multiple steps are configured, the workflow always starts with the first step in the list. Subsequent step order is controlled solely and completely by the Next Step fields within preceding workflows steps.
Most fields in steps accept templated rule engine values. This means that you can place any rule engine expression in square-braces like this:
This is a message with [DN] the DN of an object.
Workflow step rules will be evaluated in the context of the object that triggered the workflow.
If you need to use literal square braces inside a step value, the opening brace must be escaped like this: \[
Sometimes you want a step to be available to be queued by an action link, e.g. in an email notification. This may be accomplished with the Link() function.
- Azure Delicense User – removes a user's license
- Azure License User – assigns a license SKU to a user
- Azure PowerShell – runs an arbitrary PowerShell against an Azure provider tenant
- Download Report – saves a copy of a report to the file system
- Send Email – sends an email notification
- Send Report – downloads one or more reports and attaches them to an email notification
- Run PowerShell Script – executes an arbitrary PowerShell script, optionally with interpolated Rule Engine values
- Run Program – runs an arbitrary executable
- Run Schedule – Enqueues an Identity Panel schedule
- Service Task – Starts, Stops, or Restarts a windows service
- Write Event Log – Writes data to a Windows event log
Please sign in to leave a comment.