---
sourceDocument: Australia Build workflows
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/build-workflows

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Activity definitions

# Activity definitions {#ariaid-title1}

* Release version: Australia
* 
* Updated July 16, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Activity definitions

Activity definitions in ServiceNow describe how activities in your playbook obtain necessary data when the playbook runs.
They provide default configurations and values to ensure activities execute correctly upon triggering.
Each activity definition includes core configuration details, an automation plan, and an optional activity experience.
Show full answer Show less  
Activity definitions are stored in the **Activity Definition \[syspdactivitydefinition\]** table and can be managed via Process Automation \> Process Automation Administration \> Activity Definitions. These definitions enable you to add configurable activities to playbooks within Workflow Studio.

## Key Features

* **Core Fields:** Include a label for display, associated table for input records (commonly Task or Global), application scope, access roles, and an optional description.
* **Visibility Configuration:** Activity inputs can be set to always show, show as additional options, or show only for playbook admins, allowing tailored user interfaces for playbook authors and admins.
* **Automation Plan:** Defines the Workflow Studio flow or action that drives the activity's automation and the inputs required to run the activity.
* **Activity Experience:** Optional configuration specifying how the activity appears as a playbook card, including which data to render and the experience type (such as Record or Knowledge).
* **Dynamic Data Rendering:** Use the data pill picker to map dynamic data from the associated record or underlying subflow/action to fields on the playbook card, enhancing user context during playbook execution.
* **Playbook Actions:** You can assign actions that appear as buttons on the playbook card, enabling server scripts, client actions, or UI components to be triggered directly from the card.
* **AI Agent Integration:** AI Agents can be enabled for form-based activities in two modes: Collaborative (AI suggests values for human approval) or Autonomous (AI performs updates and advances playbook automatically). You can control which AI actions are allowed autonomously.

## Design Considerations

* Avoid using triggered Workflow Studio flows in activity automation plans to prevent unintended execution outside of playbooks; prefer subflows or actions with appropriate triggers.
* Predefine default input values in activity definitions to simplify and speed up playbook creation for playbook owners.

## How to Create and Configure Activity Definitions

* Define the automation plan by selecting the subflow or action the activity will run.
* Configure the inputs that playbook designers will set when adding the activity.
* Optionally configure the activity experience to tailor how the activity renders in playbook cards.
* Create example actions as automation plans to use as activities within playbooks.

## Additional Information

UI Layouts define the properties and components presented when an activity renders as a card in a Playbook experience. This enables a rich and user-friendly interface for end users interacting with playbook activities.  
Activity definitions describe how the activities in your playbook get the data that they need when your playbook runs.

Activity definitions provide default configurations and values for your activities so that they can run properly when your playbook is triggered. Each activity definition contains some basic configuration details, as well as an automation plan and activity experience.

The Activity Definition \[sys_pd_activity_definition\] table lists the definitions for the activities that you can add to a playbook in Workflow Studio. To access these activity definitions, navigate to Process AutomationProcess Automation AdministrationActivity Definitions.

## Fields {#activity-definitions__section_v2r_24p_rlb}

Each activity definition record has these basic fields:{#activity-definitions__table_ezy_jn4_rlb__entry__2}

| Field | Description |
|-|-|
| Label | Name of the activity to display to users in Workflow Studio. |
| Table | Name of the table whose records the activity can access as inputs. Typically, this table is either the Task \[task\] or Global \[global\] table. |
| Application | Application scope that the activity can run in. |
| Accessible From | Options include: * All application scopes - Users can access this activity from any application scope. * This application scope only - Users can access this activity from the application scope that you specify in the Application field only. {#activity-definitions__ul_k1n_4hb_zlb} |
| Required Roles | A list of user roles that are allowed to access activities that use this activity definition. |
| Description | Optional description for the activity. |
[ ]

{#activity-definitions__table_ezy_jn4_rlb}

## Visibility for activity inputs {#activity-definitions__section_pth_255_xjc}

Activity designers can configure the visibility of each activity input.

Always show
:   Displays the input in the properties panel.

Show as additional property
:   Displays the input in the properties panel only when playbook authors select Show additional options.

Show as additional property for Playbook admins only
:   Displays the input in the properties panel when users with the playbook.admin role select Show additional option. The input is hidden for any other users.

## Automation plan {#activity-definitions__section_fbd_jr4_plb}

Each activity definition has an automation plan. The automation plan for an activity definition specifies:

* The Workflow Studio flow or action, which drives the activity's automation
* The activity's inputs, which are the data that the activity needs to run your playbook
{#activity-definitions__ul_mlg_qfp_rlb}

## Activity experience {#activity-definitions__activity-experience}

Each activity also has an optional activity experience. The activity experience specifies an experience type, associated record, and details for what data to render in the activity's associated playbook card. Activity experience configurations only apply to activities that you add to a playbook which has an associated Playbook user experience.

Experience type
:   An experience type defines the data, or properties, that describe how the activity renders as a playbook card at runtime. For example, a Record experience type can display a title, tagline, description,
    footer, and service level agreement (SLA) information in the Playbook card. This information displays when your activated playbook runs. For more information, see [UI Layouts](https://servicenow-prod.fluidtopics.net/2aQht1gdhm2cRy7lrUDwNQ "A UI Layout describes what properties and components to use when an activity renders as a card in a Playbook Experience.").

Associated record
:   The associated record defines the record whose data can render within a Playbook card at runtime. The associated record is dynamic, which means that it changes frequently as the playbook progresses. You can use the data pill picker (![Data pill picker]()) to map the associated record to output record data. The output record data is within the underlying subflow or action specified in the automation plan.

Data to render in the Playbook card
:   You can specify the data to render in the Playbook card in the sections under the Associated Record section. To add dynamic data to fields that render in this user-facing view, use the data pill picker ![Data pill picker]() next to a data field and navigate, or dot-walk, to the appropriate data pill. The data pill should point to data within the subflow or action specified in the activity definition's automation plan.  
    Note:  
    An activity experience contains many sections where you can specify the data to appear within the Playbook card. These sections vary depending on the experience type that you select. For example, a Record experience type has Details, Form, Attachments, and Features sections, while a Knowledge experience type has Knowledge, Details, and Features sections. For more information, see [UI Layouts](https://servicenow-prod.fluidtopics.net/2aQht1gdhm2cRy7lrUDwNQ "A UI Layout describes what properties and components to use when an activity renders as a card in a Playbook Experience.").

Actions to render in the Playbook card

:   You can specify the Playbook actions that you want to render in an activity's Playbook card using the Playbook Experience Action Assignment Map related list. A Playbook action displays as a button in the Playbook
    card's footer. Playbook actions can run server scripts, dispatch client actions, or render UI components. For more information.

    To add a Playbook action to your activity definition, select New in the Playbook Experience Action Assignment Map related list. Then, choose a Playbook action from the Action Assignment list. Next,
    choose a Playbook user experience that
    you want the Playbook action to appear in from the Playbook Experience list, and then click Submit.

## AI agents {#activity-definitions__ai-agents-activity}

You can enable and configure AI Agents for all form-based activities. If you enable AI Agents for an activity definition, playbook authors can choose how to use AI Agents for the activity. The AI Agents can be used in either of
the following modes:

Collaborative
:   The AI Agents generate and fill the values, then wait until a human reviews and approves the AI-generated value.

Autonomous
:   The AI Agents can update the record, complete the activity, and automatically move the playbook to the next activity. In the activity definition, you can specify which actions you want the AI Agents to perform autonomously. For example, you can remove the option for AI Agents to complete an activity autonomously.

## Design considerations {#activity-definitions__section_hc4_5mm_tlb}

Refer to these design considerations when working with activity definitions:

Avoid calling triggered Workflow Studio flows in an activity's automation
plan
:   To prevent unintentionally running a flow outside of Playbooks, you
    can use only subflows or actions in activity automation plans. Alternatively, you can set the
    flow's trigger to only run if not already running. For more information, see [Workflow Studio flow trigger types](https://servicenow-prod.fluidtopics.net/Soppqn4o7y_LAxzJX99Zpw "Each trigger type defines when a flow starts and the starting data available to it. There are triggers for record operations, dates, and application operations.​").

Specify default input values in your activity definitions
:   Preconfiguring default input values for your activity definitions reduces the time and complexity needed for a playbook owner to create a playbook.
* **[Create an activity definition](https://servicenow-prod.fluidtopics.net/YKo~qF7plLOp9f6SFvnhRg)**   
  Specify the action or subflow you want an activity to run. Configure the inputs you want playbook designers to set when adding the activity to a playbook. Select the experience you want end users to have when the activity runs.
* **[Create an action as an activity automation plan](https://servicenow-prod.fluidtopics.net/U8USpWbyPCZOzsgU_dss9w)**   
  Create an example action to configure and run as an activity from Playbooks.
* **[UI Layouts](https://servicenow-prod.fluidtopics.net/2aQht1gdhm2cRy7lrUDwNQ)**   
  A UI Layout describes what properties and components to use when an activity renders as a card in a Playbook Experience.

*[\>]: and then