Playbook Button Triggers

playbook button triggers create interactive buttons in application records that, when clicked, execute a playbook with the current record's data unlike automatic triggers (like record event or schedule triggers), button triggers give users control over when to execute a playbook, making them ideal for manual workflows, approvals, or user initiated actions key benefits manual control users decide when to execute the playbook by clicking the button record context full access to the current record's data when the playbook runs seamless integration buttons appear directly in the application record interface flexible configuration create buttons from the playbook canvas or application builder reusable buttons multiple playbooks can use the same button, or create new buttons as needed no flow rebuilds buttons can be added or modified without requiring reconstruction of the entire flow how to create playbook button triggers you can create a playbook button using two methods from the playbook from the application method 1 create playbook button from a playbook from the add section, drag and drop playbook button to the canvas click on the added playbook button to view the trigger configuration panel in the application dropdown menu, select the desired application the dropdown shows all available applications in your tenant you can filter applications by typing in the search box once selected, a link appears to "open application in a new tab" for quick access in the button label dropdown menu click create new to create a new playbook button (a unique name will be generated automatically, e g , "button 1", "button 2") or select an existing playbook button from the dropdown note buttons that are already triggering a different flow will be disabled and show a tooltip if you selected create new , a notice appears "saving this playbook will create a new button in the application " save the playbook to finalize the button creation note the button will appear in the selected application's record view once the playbook is saved method 2 create playbook button from the application to create a playbook button from the application builder navigate to applications and applets either select an existing application or click the plus icon to create a new one click and drag playbook button to the form layout section on the field properties tab edit the button label if desired (this is the text that appears on the button) from the playbook dropdown menu, select the playbook that this button will trigger when clicked on an application's record the playbook must be published and enabled to be selectable click save to finalize your button creation note when creating a button from the application builder, the button is immediately available in the application if you later add a playbook button trigger to a playbook and select this existing button, the playbook will be associated with that button playbook button trigger outputs when a playbook button is clicked, the playbook receives event data containing the current record's information this data can be accessed in your playbook actions event data structure $event data application information about the application id application id uid application uid name application name $event data currentuser information about the user who clicked the button id user id username username issystemuser boolean indicating if the action was performed by the system $event data record current record data id record id (internal identifier) url url to view the record in the ui values object containing all field values (keyed by field key) note unlike record event triggers, button triggers do not provide previous values since they are not triggered by record updates accessing record data in playbooks you can access record data in your playbook actions using the $event data prefix examples note field values are accessed using field keys (not field ids or names) field keys are typically lowercase with hyphens (for example priority level , assigned to ) event metadata event type record event action button (triggered by button click) event fqn turbine record button event source turbine example 1 manually initiating a critical alert workflow scenario a soc analyst needs to manually escalate certain incidents to a critical alert status when they determine that a high severity incident requires immediate attention the playbook button trigger allows them to initiate a remediation workflow directly from the incident management application configuration create the playbook button trigger from the playbook canvas, drag and drop the playbook button trigger in the application field, select the incident management application in the button label field, select create new and name the button escalate to critical save the playbook to create the button in the application add a condition action drag a condition action into the flow check if $event data record values incident state does not equal "critical" if true, proceed with escalation; otherwise, inform the user create variables drag a create variables action into the flow create variables incident id $event data record id priority level $event data record values priority level incident state $event data record values incident state add update/create record action drag an update/create record action into the flow configure to update the incident state to critical use key field $event data record values tracking id patch value incident state = "critical" add http action for notification drag an http action into the flow configure post request to external notification system (e g , pagerduty or slack) endpoint https //api pagerduty com/incidents payload {"incident id" "{{$variables incident id}}", "priority level" "{{$variables priority level}}", "status" "critical"} add send notification action drag a send notification action into the flow configure to notify the security team title "incident escalated to critical" body "incident {{$variables incident id}} has been escalated to critical status priority {{$variables priority level}}" result when the analyst clicks the "escalate to critical" button, the incident is automatically updated to critical status, and notifications are sent to external systems and the security team if the incident is already critical, the user is informed example 2 manual incident closure with verification scenario an analyst needs to manually close an incident after verifying resolution the playbook button allows them to close the incident, update external systems, and notify stakeholders with a single click configuration create the playbook button trigger from the playbook canvas, drag and drop the playbook button trigger in the application field, select the incident management application in the button label field, select create new and name the button close incident save the playbook to create the button add a condition action drag a condition action into the flow check if $event data record values resolution summary exists (is defined) if true, proceed with closure; otherwise, inform the user that a resolution summary is required create variables drag a create variables action into the flow create variables incident id $event data record id closure time current timestamp resolution summary $event data record values resolution summary add update/create record action drag an update/create record action into the flow configure to update the incident status to closed use key field $event data record values tracking id patch value incident state = "closed" add parallel action drag a parallel action to execute multiple tasks simultaneously branch 1 send notification to stakeholders branch 2 http action to update external system (servicenow/jira) branch 3 http action to log closure in separate system configure branch 1 send notification drag a send notification action configure to notify assigned users/groups title "incident closed {{$variables incident id}}" body "incident has been closed resolution {{$variables resolution summary}}" configure branch 2 update external system drag an http action configure put request to external ticketing system endpoint https //api servicenow\ com/api/now/table/incident/{{$event data record values external ticket id}} payload {"state" "closed", "close code" "resolved"} result when the analyst clicks the "close incident" button, the incident is automatically closed, external systems are updated, and stakeholders are notified if a resolution summary is missing, the user is prompted to add one first example 3 export record data to external system scenario an analyst needs to export incident data to an external system for further analysis the playbook button allows them to trigger the export with current record data configuration create the playbook button trigger from the playbook canvas, drag and drop the playbook button trigger in the application field, select the incident management application in the button label field, select create new and name the button export to external system save the playbook to create the button create variables drag a create variables action into the flow create variables to store record data incident id $event data record id incident data $event data record values (entire record values object) add http action drag an http action into the flow configure post request to external system api endpoint https //api externalsystem com/incidents method post body type json body add send notification action drag a send notification action into the flow configure to notify the user who clicked the button title "export successful" body "incident {{$variables incident id}} has been exported to the external system " result when the analyst clicks the "export to external system" button, the current incident data is sent to the external system, and the user receives a confirmation notification best practices clear button labels use descriptive button labels that clearly indicate what action will be performed (e g , "escalate to critical" instead of "button 1") user feedback always provide feedback to users after button clicks, either through notifications or by updating the record status error handling include error handling in your playbooks to handle cases where button actions might fail (e g , external api failures, missing required fields) button availability consider using conditions or record restrictions to control when buttons are available or enabled avoid infinite loops be careful when updating records in playbooks triggered by buttons, as this won't create infinite loops but may cause unexpected behavior test thoroughly test button triggers with various record states to ensure they work correctly in all scenarios documentation document what each button does so users understand the consequences of clicking it access control ensure users have appropriate permissions to execute the playbook and access the record data troubleshooting button not appearing verify the playbook is published and enabled check that the application is correct ensure the button label is configured refresh the record page button disabled buttons are disabled if they're already triggering a different flow check if another playbook is using the same button create a new button if needed playbook not executing verify the playbook is published and enabled check playbook run history for errors verify user has permissions to execute the playbook check that the application and button configuration are correct field values not accessible verify you're using field keys (not field ids or names) check that fields exist in the application ensure field keys match exactly (case sensitive) use $event data record values fieldkey format record data missing button triggers provide current record data only (no previous values) ensure the record is saved before clicking the button check that the record has the expected field values external api failures add error handling in your playbook check api endpoints and authentication verify network connectivity use retry/repeat settings for http actions