Actions are tasks that are defined within a Workflow. An Action can be any type of work that needs to be completed, such as data entry, review, or approval.

Overview

Actions page is available in the Administration application → Services & Processes → Workflow Designer →  Actions.  The Workflow Designer Actions page lists and allows managing the Workflow Designer actions, showing the basic information like name, category, and implementation type.

Workflow Activities

Push Notification 

The AI-Native Workflow Designer now supports a Send Push Notification action, allowing workflows to notify responsible users in real time via in-app alerts or Microsoft Teams, depending on user settings.

Key Capabilities

• Customizable alert content: define Title and Body with static text or dynamic placeholders (e.g., Ticket ID, Summary, Impact).
• Targeted delivery:  notify responsible users, decision makers, or specific roles based on workflow logic.
• Multi-channel support: notifications can be delivered in-app or directly into Microsoft Teams.
• Configurable options: adjust category, event type, item context, and even notification sounds.
• Deep links to objects: use Item Entity Name and Item Object to automatically generate a direct link to the referenced object (e.g., Incident, Service Request, Approval).
• Links: include URLs for direct navigation to the relevant ticket, service, or workflow context.

Send Email Action 

Workflow automation in the AI-Native Workflow Designer now includes a Send Email action, enabling dynamic stakeholder communication directly within workflows.

Key Capabilities

• Customizable email content: define Subject and Body with static text or dynamic placeholders (e.g., Ticket ID, User, Category, Urgency).
• Dynamic content: insert workflow data fields such as ticket type, impact, or responsible role from the Workflow Context to personalize notifications.
• Email signature support: select predefined signatures for consistent corporate communication.
• Priority control: set message priority for critical escalations.
• Flexible recipients configure static addresses or use dynamic recipient fields (e.g., requester, manager, responsible role).
• Inline preview: review the complete email content before activating the workflow.

Why It Matters

• Ensures timely stakeholder communication as part of automated processes.
• Reduces reliance on external notification tools by embedding communication into workflows.
• Improves transparency and accountability with automated status updates and alerts.

Add Journal Entry

The Workflow Designer now includes an “Add Journal Entry” action, enabling workflows to automatically record contextual updates directly in the journal of related activites (e.g., Incidents, Service Requests, Changes).

Key Capabilities

• Customizable journal entries: define entry type (e.g., AI Triage, System Update) and attach detailed comments.
• Linked to objects: entries are stored against the selected record (e.g., ticket) to ensure a complete activity history.
• Automated updates: journal entries can include AI-detected values (ticket type, category, urgency, impact, priority) as well as workflow actions (responsible team assignment, notifications sent, escalations triggered).
• Creator context: specify who the journal entry appears from (e.g., AI Agent, Workflow System, or designated role).
• Audit & transparency: every AI-driven or automated action is fully traceable, improving accountability and compliance.\

Transform Ticket 

A new workflow activity/action Transform Ticket is now available in both Workflow Studio and the AI-Native Workflow Designer. This action allows you to seamlessly convert tickets between types (e.g., Service Request ↔ Incident).

Key Capabilities

• Transform Ticket: change the type of a ticket to Incident or Service Request within workflows.
•  Automatic defaults: when a ticket is transformed, the default category and default role of the new target type are automatically applied.
• Workflow Studio & Workflow Designer: the activity is supported across both workflow tool for full backward compatibility and forward innovation.

Why It Matters

• Provides flexibility for automation scenarios where ticket type may change during processing (e.g., a general request escalated to an Incident).
• Ensures consistency by automatically applying target-type defaults without manual adjustments.
• Simplifies workflow design and improves service desk efficiency.

Condition Builder for If/Then/Else and Switch 

We’ve enhanced the Workflow Designer with a powerful Conditional Builder that allows users to define complex branching logic without coding.

Key Capabilities

• If/Then/Else branching – build conditions that check multiple attributes (e.g., Ticket Category, Impact, Asset presence) and define the follow-up path.
• Switch conditions – easily handle multiple outcomes from a single attribute with structured branching.
• Visual Condition Builder – create conditions through a drag-and-drop interface and logical operators (AND/OR).
• Multiple condition groups – combine attribute checks (e.g., If Category = Security AND Asset is set).
• Inline documentation – add comments to clarify the purpose of each condition for other workflow designers.

Parallel & Serial Execution (Approvals & other Actions)  

The AI-Native Workflow Designer now supports Parallel Execution blocks, allowing workflow designers to orchestrate approvals and other actions with flexible execution logic.

Key Capabilities

• Parallel Execution (OR): multiple approval or action branches can run at the same time; the workflow continues once any branch is completed.
• Serial Execution (AND): actions or approvals are processed sequentially; the workflow continues only once all defined branches are completed.
• Approvals: approvals can be sent to managers, technical owners, cost centers, or other stakeholders in parallel or serial mode.
• Other actions: not limited to approvals; can be applied to tasks, tickets, changes, or any workflow activity that requires orchestration.
• Merge Execution: parallel branches can be merged back into a single flow for continued processing.

Change Management Actions (Create, Update & Close Change)

The AI-Native Workflow Designer adds three actions that manage the full change record lifecycle directly from the workflow canvas: Create Change, Update Change, and Close Change.

Key Capabilities

• Create Change opens a new change request, populating core fields such as Category, Summary, Description, Type of Change, and Classification (Minor, Significant, Major), and can pre-fill the request from a Change Template
• Create Change captures planning details — Timeline, Cost Estimation, Known Risks, Counteractions, and Roll-back Strategy — plus ownership via Responsible User/Role, Reviewers, Creator, and the affected User, and can start the change's workflow immediately on creation
• Update Change targets an existing Change record to revise its Status, append a Journal Entry (optionally visible in the self-service portal), and update planning, classification, or ownership fields
• Update Change and Create Change can both link the change to Related Incidents, Problems, Services, Assets, Bookings, Simple Service Forms, and Topics, and configure SLA, Resubmission date, Reporting Channel, and Notification Mode
• Close Change targets a Change record and requires a Reason (from a predefined closure pickup list) and a Solution describing how or why the change was resolved
• Available in both classic Workflow Studio and the AI-Native Workflow Designer

Why It Matters

• Automates the entire change record lifecycle — create, update, close — without leaving the workflow canvas
• Keeps change documentation, ownership, and risk assessment consistent across every request
• Reduces manual console work for standard, normal, and emergency changes alike

Close Task

The AI-Native Workflow Designer includes a Close Task action that marks a task as completed and removes it from the list of open items.

Key Capabilities

• Targets a specific Task record to close
• Requires a Reason, selected from a predefined closure pickup list, to categorize the outcome (e.g. completed, rejected)
• Requires a Solution describing how or why the task was resolved

Delete Record

The Delete Record action removes records from the database directly from the workflow.

Key Capabilities

• Specifies the Configuration Item (CI) type to target — for example Computer, Server, Application, or any other configured CI type
• Accepts one or more object references (Objects); when multiple are provided, the action is executed for every referenced record

Run Subworkflow

Overview

The Run Subworkflow action starts any released workflow from within the current workflow. The target workflow does not need to use the Invocation Trigger — you can select any released workflow, regardless of its trigger.

Key Capabilities

• Any released workflow as a target: select any released workflow, independent of its trigger type. The target workflow list includes both workflows built in the AI-Native Workflow Designer and in Workflow Studio.
• Trigger-dependent arguments: the arguments you can configure depend on the target workflow's trigger:
  • If the target workflow uses the Invocation Trigger, you can configure the custom arguments defined on that trigger.
  • If the target workflow uses a different trigger, such as On Record Update, only the predefined ObjectContexts argument is available. Use it to pass the relevant object context from the current workflow to the target workflow.
• Decoupled execution: the target workflow runs as its own workflow instance, separate from the workflow that started it.
  
• Run Asynchronously: controls whether the current workflow waits for the target workflow to finish. When enabled, the current workflow continues immediately, and the output arguments from the target workflow are not available to later actions in the current workflow.
• Ignore Failure: controls whether the current workflow continues running if the target workflow fails.

Configuring the Run Subworkflow Action

1. Add the Run Subworkflow action to your workflow.
2. In the Workflow field, select the released target workflow to start. This list includes both AI-Native Workflow Designer and Workflow Studio workflows.
3. Configure the arguments passed to the target workflow:
   • For a target workflow using the Invocation Trigger, provide values for the custom arguments defined on that trigger.
   • For a target workflow using a different trigger, provide the ObjectContexts value, if available.
4. Optional: use Related Objects to set object contexts for the target workflow, instead of setting them in the Arguments table.
5. Optional: enable Run Asynchronously if the current workflow should continue without waiting for the target workflow to finish. Leave this disabled if later actions in the current workflow need the target workflow's output arguments.
6. Optional: enable Ignore Failure if the current workflow should continue running even if the target workflow fails.
7. Save the workflow.

Why It Matters

• Enables workflows to reuse existing automation instead of rebuilding the same logic in multiple places.
• Reduces workflow complexity by delegating specific tasks to dedicated subworkflows.
• Keeps large processes maintainable by breaking them into smaller, independently released workflows.
• Supports workflows from both the AI-native Workflow Designer and Workflow Studio, so existing automation can be reused without rebuilding it in the AI-Native Workflow Designer.
• Provides control over execution behavior, allowing workflows to run subworkflows synchronously or asynchronously, and to tolerate or halt on subworkflow failure, depending on the process requirements.

Assign Output Parameters

Overview

The Assign Output Parameters action sets values for the output arguments defined on the Invocation Trigger of the current workflow.

Add this action anywhere in the subworkflow where an output value becomes available. When the subworkflow finishes, the values assigned by this action become available to the parent workflow that called it, through the Run Subworkflow action.

Key Capabilities

• Assign output argument values: set a value for each output argument defined on the workflow's Invocation Trigger.
• Use anywhere in the workflow: add the action at any point in the subworkflow, not only at the end, so output values can be assigned as soon as they become available.
• Last value wins: if the action is used multiple times for the same output argument, the last assigned value is the one returned to the parent workflow.

Configuring the Assign Output Parameters Action

1. Add the Assign Output Parameters action to the workflow, at the point where the output value becomes available.
2. In the table, set a value for each output argument you want to assign. Only output arguments defined on the workflow's Invocation Trigger are available here.
3. Save the workflow.

Why It Matters

• Makes subworkflow results available to the parent workflow, enabling further processing based on the subworkflow's outcome.
• Supports assigning output values as soon as they are known, rather than only at the end of the workflow.
   

Triggers

Record Creation & Update 

Workflow automation is now more flexible with new record-based triggers in Workflow Designer.

Key Capabilities

• On Record Creation – start a workflow whenever a new record is created (e.g., a new Incident or Service Request).
• On Record Update – start a workflow when an existing record is updated (e.g., urgency changed, status updated).
• ️ Multi-configuration item support – multiple configuration items that share the same data definition can be selected for a single trigger (e.g., Incident + Service Request).
•  Validation included – items with different data definitions (e.g., License and Computer) cannot be combined to avoid invalid triggers.

Why It Matters

• Enables powerful event-driven automation without scripting.
• Reduces complexity by letting admins reuse a single trigger across multiple but related configuration items.
• Improves process consistency across Incident and Request handling while keeping system integrity intact.

Invocation Trigger

Summary 

This article explains how to create a subworkflow using the Invocation Trigger, how to configure its integration context, and how to define the arguments a parent workflow or UI action can pass to it.

Overview

The Invocation Trigger starts a workflow only when it is called directly, rather than in response to a record event such as creation or update. A workflow that starts with the Invocation Trigger is called a subworkflow.

A subworkflow using the Invocation Trigger can be called in different ways, depending on its Custom Integration Context:

• From another workflow, using the Run Subworkflow action.
• From a UI action, once the subworkflow is released with the Custom Integration Context set to Actions.

Use the Invocation Trigger to build reusable pieces of logic that other workflows or UI actions can call with their own input values, instead of duplicating the same steps across multiple workflows.

Key Capabilities

• Integration context: define how the subworkflow can be called — from another workflow using the Run Subworkflow action, or from a UI action.
• Custom arguments: define the arguments that must be provided when the subworkflow is called, and the output arguments it returns. Output argument values are set using the Assign Output Parameters action.
• Argument data types: configure the data type for each argument, so the calling workflow or UI action provides matching values.
• Reusable logic: the same subworkflow can be called from multiple parent workflows or UI actions, each providing its own argument values.

Creating and Configuring the Trigger

1. Open the Workflow Designer and create a new workflow with the Invocation Trigger.
2. Click + Add to define an argument and configure the following:
   1. Title: choose a title for the new argument. 
   2. Description: optional description to give more context on the argument. 
   3. Direction: whether the argument is passed into the subworkflow, returned from it, or both.
   4. Data Type: the type of value this argument accepts.
      • Data Type Configuration: additional settings specific to the selected data type.
   5. Required: whether a value must be provided when the subworkflow is called.
   6. Multiple: whether the argument accepts more than one value.
      

      

3. Repeat steps 2–3 for every additional argument the subworkflow needs.
   

   Note: To set a value for an output argument, use the Assign Output Parameters action anywhere in the subworkflow.

    
4. Optional: to make the subworkflow available as a UI action instead of only through the Run Subworkflow action, set the Custom Integration Context field in the trigger configuration to Actions. Leave this field empty to call the subworkflow only from another workflow using the Run Subworkflow action.
5. Save and release the workflow.

Making a Workflow Available as a UI Action

When the Custom Integration Context of the Invocation Trigger is set to Actions, the released workflow becomes available for selection in the relevant UI action configuration. Users can then start the workflow directly from the UI, using the arguments defined on the Invocation Trigger.

For more information about configuring UI actions, see Actions.

Why It Matters

• Reduces duplicated logic by letting multiple workflows or UI actions call the same subworkflow instead of repeating the same steps.
• Simplifies maintenance, since updates to the subworkflow apply automatically to every workflow or UI action that calls it.
• Supports modular workflow design, making individual subworkflows easier to test and troubleshoot on their own.
• Extends automation beyond workflows, allowing end users to trigger the same logic directly from the platform UI.