Setting Up Integration Workflows

Integration workflows let you automate outgoing actions — like updating a HubSpot deal or creating a ServiceNow CI — whenever a lifecycle event occurs in Patrol. This guide walks through the HubSpot → ServiceNow scenario described in the lifecycle hooks concept page.

Prerequisites

• At least one integration configured and enabled (e.g. HubSpot)
• If your workflow spans multiple integrations, each one must be set up first

Scenario

A HubSpot deal closes (Won). Patrol provisions the customer and environment. Once the customer record exists, Patrol writes the new Patrol customer ID back to the HubSpot company. Once the deployment succeeds, Patrol notifies ServiceNow’s CMDB with environment metadata, and updates HubSpot again to mark the deal as live.

This requires two workflows:

1. On customer.created → update HubSpot company with Patrol customer ID
2. On deployment.succeeded → create ServiceNow CI, then update HubSpot deal status

1. Create the customer-created workflow

1. Navigate to Integrations in the sidebar and open your HubSpot integration
2. Click the Workflows tab
3. Click New Workflow
4. Fill in:
   • Name: Customer Created → Update HubSpot Company
   • Lifecycle Hook: customer.created
5. Click Add Step and configure:
   • Action: hubspot:update_company
   • Integration ID: (your HubSpot integration ID — pre-filled by default)
   • Field Mapping:
     • companyId ← customer.hubspotCompanyId
     • patrol_customer_id ← customer.id
     • patrol_customer_name ← customer.name
6. Click Create Workflow

Now, whenever a new customer is created from a HubSpot deal, Patrol will automatically write the Patrol customer ID back to the HubSpot company record.

2. Create the deployment-succeeded workflow

1. Still on the Workflows tab, click New Workflow again
2. Fill in:
   • Name: Deploy Complete → CMDB + HubSpot
   • Lifecycle Hook: deployment.succeeded
3. Step 1 — Create ServiceNow CI:
   • Action: servicenow:create_ci
   • Integration ID: (your ServiceNow integration ID)
   • Field Mapping:
     • name ← environment.name
     • environment ← environment.envType
     • operational_status ← live (literal value — no dot, passed through as-is)
     • owned_by ← customer.name
   • Continue on error: checked (so step 2 runs even if ServiceNow fails)
4. Step 2 — Update HubSpot deal:
   • Action: hubspot:update_deal
   • Integration ID: (your HubSpot integration ID)
   • Field Mapping:
     • dealId ← (you’ll need the deal ID — see note below)
     • patrol_status ← live
5. Click Create Workflow

Getting the deal ID into deployment context

The deployment.succeeded hook’s context includes the customer, environment, and run — but not the original HubSpot deal ID. To pass it through, store the deal ID in your environment’s deployment parameters (via the HubSpot field mapping) so it’s available as environment.deploymentParameters.dealId at deploy time. A future enhancement will support custom context fields.

Execution model

• Steps within a workflow execute sequentially in sort order
• Multiple workflows on the same hook execute in parallel
• If a step fails and Continue on error is unchecked, the remaining steps in that workflow are skipped
• Each step execution is logged as an outbound event in the Event Log tab

Scoping: tenant vs. template

By default, workflows apply tenant-wide — they fire for any environment in the tenant. To scope a workflow to a specific service template:

1. When creating the workflow, set the Service Template ID field to the target template’s UUID
2. The workflow will only fire for lifecycle events involving environments created from that template

Template-scoped workflows merge with tenant-wide workflows. If you have a tenant-wide deployment.succeeded workflow and a template-specific one, both will fire.

Available actions

HubSpot

Action	Description	Required fields
hubspot:update_deal	Update properties on a HubSpot deal	dealId + any property names
hubspot:update_company	Update properties on a HubSpot company	companyId + any property names

ServiceNow

Action	Description	Required fields
servicenow:create_ci	Create a Configuration Item in the CMDB	name, and optionally sys_class_name, environment, operational_status
servicenow:update_ci	Update an existing CI	sys_id + any fields to update
servicenow:update_change	Update a change request	sys_id + dynamic field mapping for change fields
servicenow:update_incident	Update an incident	sys_id + dynamic field mapping for incident fields
servicenow:create_record	Create a record in any table	table + record fields
servicenow:update_record	Update a record in any table	sys_id, table + fields to update

Note: Graph workflows (canvas editor) are now the recommended approach. The legacy integration workflows feature will be deprecated in a future release. See the Workflows guide for the new pattern.

Monitoring

All outgoing workflow step executions appear in the Event Log tab with a direction badge:

• Inbound (↙) — webhook events received from external systems
• Outbound (↗) — actions triggered by workflows

Failed steps include the error message in the event log, making it straightforward to diagnose issues.

Next steps

• Integration lifecycle hooks — full reference of available hooks and context payloads
• HubSpot integration — setting up HubSpot as an inbound trigger