{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":44497,"path":"security-management/security-incident-response/example-activity-definition-send-email.md","title":null,"bundle":null,"doc_type":null,"release":null,"body":"---\ntitle: Example Activity Definition: Send email\ndescription: The following is an example of Send email activity definition.\nlocale: en-US\ncanonical_url: https://www.servicenow.com/docs/r/australia/security-management/security-incident-response/example-activity-definition-send-email.html\nrelease: australia\nproduct: Security Incident Response\nclassification: security-incident-response\ntopic_type: concept\nlast_updated: \"2026-03-12\"\nreading_time_minutes: 7\nbreadcrumb: [Activity Definitions, Use, Security Incident Response Workspace, Security Incident Response, Enterprise security case management applications, Security Operations]\n---\n\n# Example Activity Definition: Send email\n\nThe following is an example of Send email activity definition.\n\n## Basic\n\nThe basic details capture the name \\(label\\), application, description, table, and from all the applications it’s accessible from.\n\nAdd the Automation plan, Activity experience and submit. After submitting, edit the document to add more details against each tab.\n\n## Automation Plan\n\nThe Automation Plan associates the backend action or subflows built using the flow designer. This example uses: **Send Email - ESCM Activity** subflow.\n\nThis subflow enables sending an email. It has the core logic to send an email. It has all the input fields and output fields defined.\n\nAll the input fields are shown within the automation plan section. Each input field can be enabled to be visible only for the admin, in the standard modal, in the standard modal and the configuration panel:\n\n-   **Admin visibility only**: when set to admin, only admin can view it.\n-   **Include in standard model**: when set to view in the standard modal, it appears only in the properties modal.\n-   **Include in standard model and configuration panel**: when set to view in the standard modal and the configuration panel, it appears in the PAD configuration panel as well as in the properties modal. For more information, see [Activity definitions](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/build-workflows/activity-definitions.md)\n\nYou can define the input fields at the time of activity definition itself, provided you don't have any need to change these values at the time of configuration. This helps the business process owner save time while configuring an activity within a process.\n\n## Activity Experience\n\nThe activity experience tab defines how the activity card is rendered at run time. The base system provides the following experience types:\n\n-   Approval\n-   Catalog Item\n-   Create Record\n-   Instructional\n-   Knowledge\n-   List\n-   Notification\n-   Record\n\nBased on the type of experience you select, the further fields are populated. For more information, refer the ServiceNow AI Platform documentation.\n\nIn this example, **Record** type is selected.\n\n**Note:** For example, if you want to render a table, you can choose list as the experience type.\n\n## Associated Record\n\nUse this record to store the associated data pertaining to the current activity. This would capture the run time data, as well the status of the experience.\n\n-   Associated table: Flow Data\n-   Associated Record: VL\n-   Experience status table: Flow Data\n-   Experience Status record: VL\n\nIn this example, Flow data table is used to capture the run time data. The run time data can vary based on the use case. In this example, the run time data are fields like To, cc, Subject, and body. For each use case, a flow data definition needs to be created to define the type of the run time data.\n\n1.  Navigate to the left pane and enter **sys\\_flow\\_data\\_definition.list**. It displays the list of definitions created for the flow data table.\n\n    \\[Omitted image \"data-def.png\"\\] Alt text: This is an associate record\n\n2.  Open **Email - SCM Def** to view the definition related to this example.\n\n    \\[Omitted image \"email-scm-def.png\"\\] Alt text: Email - SCM Def\n\n    This flow data definition must be used by the subflow or the action that is associated with this activity definition \\(Refer automation plan\\) to capture the run time data.\n\n    \\[Omitted image \"activity-send-email.png\"\\] Alt text: Automation Plan\n\n3.  In this example, open the subflow: **Send Email - ESCM Activity**. Under **Create Flow Data** step, the flow data definition you created is mapped against the **Definition** field. This flow data record is used across the subflow. In this example, the activity card status \\(experience status\\) is captured in the flow data table.\n\n    \\[Omitted image \"crete-flow-data.png\"\\] Alt text: Create Flow Data\n\n\n**Note:** If you want to capture the runtime data in a different table record other than flow data table, say for example in a response task. You can select the associated table as Response task table. The associated record should be set to response task record created by the subflow.\n\nSimilarly, experience status table captures the status of the activity card. In the base system, the state field of the flow data table is mapped to the activity card status. So, when flow data table is used to capture the experience status, it automatically updates the activity card status. You could also use a different table other than flow data table to capture the experience status.\n\nFor example, if you would want to map the response task status to the activity card status then that is possible. To do so:\n\n1.  Navigate to **All** > **Playbook Experiences**.\n\n    \\[Omitted image \"playbook-exp.png\"\\] Alt text: Playbook Experiences\n\n2.  Open **SIR Playbook experience**.\n3.  Open **Status Mapping** related list.\n\n    \\[Omitted image \"status-mapp.png\"\\] Alt text: SIR Playbook experience\n\n4.  Enter the **Response Task** against Experience Status Table field.\n5.  Enter the **State** against Experience Status field.\n\n    \\[Omitted image \"new-status-mapp.png\"\\] Alt text: Playbook experience Status Mapping\n\n6.  Click **Submit**. The record is created.\n\n    \\[Omitted image \"status-mapping.png\"\\] Alt text: Experience Status to Activity State\n\n7.  Under Experience Status to Activity State, map the states of response task to activity card status.\n8.  The left side shows the states of the Response Task, and the right side shows the activity card status.\n\n    \\[Omitted image \"status-map.png\"\\] Alt text: Playbook Experience Status to Activity State Map\n\n9.  The mapping can be bi-directional. Under Activity State to Experience related list as well, map the statuses correctly. This step is the reverse of the previous step. In this case, the left side shows the activity card status, and the right side shows the response task status.\n\n    \\[Omitted image \"status-map-new-rcord.png\"\\] Alt text: Playbook Experience Activity State to Experience Status Map\n\n\n## Details\n\n-   Tag Line: Send Email\n-   Icon: Envelope outline \\(not shown in the user interface\\)\n-   Title: **Activity** > **Activity Instance** > **Label**. Here we have selected the activity instance’s label. This dot-walking will replace the label value as the title dynamically at run time.\n-   Description: **Activity** > **Activity Instance** > **Description**. Here we have selected the activity instance’s description. This dot-walking will replace the label value as the title dynamically at run time.\n-   Pending State Title: Send an email notification. This is the title when the activity is in Pending status.\n-   Pending State Description: Prompts for confirmation of email subject and body before sending. This is the description of the activity card when the status is pending Record Fields: There are record fields selected in this example.\n\n    Record Fields are comma-separated list of field names to display for the associated record in a name-value pair list. Data is pre-fetched on the server, dot-walking is supported and  **canRead\\(\\)** permissions are evaluated on each field.\n\n-   Footer: There’s no footer defined for this example.\n\n    Footer is a text in a gray area of the card footer. You can add any meaningful information to shown.\n\n    \\[Omitted image \"details.png\"\\] Alt text: Activity Definition - Send Email page\n\n\n## Form\n\n-   Form View: collect\\_data\n-   Form Fields:\n\nThis example uses collect\\_data view to show the fields that must be presented to the user to enter inputs. Collect\\_data view is a platform provided view corresponding to flow data table. Alternatively, you could leave Form View as empty, and select Vars from the list of values available against Form Fields. \\(click the lock icon to open the list of available values\\).\n\n\\[Omitted image \"form.png\"\\] Alt text: Form\n\n## Attachments\n\nIn this example:\n\n-   Attachment Source is empty.\n-   Attachment Read only not selected.\n\n1.  Attachment Source - Drop down. What attachments to show on the card: Those attached to the Parent Record, the Associated Record, or none.\n2.  Attachment Read only - True or False. Prevent the user from renaming or deleting the existing attachments.\n\n\\[Omitted image \"attach.png\"\\] Alt text: Activity Definition - Send Email page\n\n## Features\n\nIn this example,\n\n-   Show SLA - Cleared\n-   Show Checklist - Cleared\n-   Is Automated - Cleared\n\nShow SLA: True / False. Renders an SLA timer in the header of the card for the Associated Record. The SLA is chosen according to the SLA Configuration record specified in the Playbook configuration.\n\n1.  Show Checklist  - True or False. Renders any checklist that is attached to the Associated Record. The checklist is editable and changes are saved without requiring a Declarative Action.\n2.  Is Automated - True or False. If true, then the  **tagline**  and  **icon**  will be overridden with the text **Automated Task** and an automated icon.\n\n\\[Omitted image \"feaures.png\"\\] Alt text: Activity Definition - Send Email Form page\n\n## Playbook Actions in Activity Definition\n\nThis section has the actions that will be rendered on the activity card. This example has **Skip**, and **Send Email** as actions.\n\nTo add a new action to the activity card, you must create a record in the **Playbook Actions** related list present at the bottom of the page.\n\n\\[Omitted image \"actions.png\"\\] Alt text: Playbook Actions\n\n1.  Select **New**.\n2.  Select existing activity action against Action Assignment field.\n3.  Select **SIR Playbook Experience** against Playbook Experience field.\n\n-   **[Create an Activity Action](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/security-incident-response/steps-to-create-an-activity-action.md)**  \nFollowing is procedure to create an activity action.\n\n**Parent Topic:**[Activity Definitions](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/security-incident-response/build-activities.md)\n\n"}}