Automation examples

​

Employee onboarding

​

What you’ll build

​

Setup

1. Create a new automation and select the User Created trigger.
2. Add a trigger condition to scope to full-time employees:

subject.employmentType == "FULL_TIME" && subject.status == "ENABLED"

3. Add a Grant Entitlements step. Select the entitlements every new employee should receive (for example, email, Slack, HRIS). Set the target user to the trigger’s subject user.
4. Add a Create Account step. Select the connector for a department-specific tool (for example, Jira for Engineering, Salesforce for Sales). Use the “From ConductorOne user data” creation method to map the user’s profile fields automatically.
5. Add a Send Slack Message step. Set the channel to #new-hires and the message to:

Welcome {{ ctx.trigger.user.display_name }} to the {{ ctx.trigger.user.department }} team! Their manager is {{ ctx.trigger.user.profile.manager_name }}.

6. Add a Send Email step. Set the recipient to {{ ctx.trigger.user.email }}, the subject to Welcome to the team, and include links to IT self-service and onboarding resources in the body.

​

Why these choices

• User Created (not Account Created) because you want to trigger on the person joining the organization, not on individual app accounts being provisioned. Account Created would fire separately for each app, which isn’t what you want here.
• The trigger condition filters to full-time and enabled users. Without it, the automation would also fire for contractors or staged users who aren’t ready for access yet.
• Grant Entitlements handles multiple apps in one step, so you don’t need a separate step per app for baseline access.

​

Testing

​

Employee offboarding

​

What you’ll build

​

Setup

1. Create a new automation and select the User Updated trigger. Set the monitored attribute to status.
2. Add a trigger condition that detects the transition from enabled to disabled:

ctx.trigger.oldUser.status == "ENABLED" && ctx.trigger.newUser.status == "DISABLED"

3. Add a Revoke Entitlements step. Set it to revoke all entitlements for the subject user. Use the Entitlements to exclude field to preserve any compliance-required archival access (for example, email archive, document retention).
4. Add a Modify User Status step. Set the target user to the subject and the new status to Disabled.
5. Add a Create Campaign step. Select an access review template that targets the subject user’s remaining access. This creates a focused review for anything the exclusion list preserved.
6. Add a Send Email step. Set the recipient to your security team distribution list. Use template syntax in the body:

{{ ctx.trigger.newUser.display_name }} ({{ ctx.trigger.newUser.email }}) has been disabled.
Department: {{ ctx.trigger.newUser.department }}
Manager: {{ ctx.trigger.newUser.profile.manager_name }}
Access revocation has been initiated. A review campaign has been created for any remaining access.

​

Why these choices

• User Updated with oldUser/newUser comparison catches the exact moment of status change. This is more reliable than a scheduled check, which would introduce delay.
• Revoking “all with exclusions” is safer than listing specific entitlements to revoke. New apps added after the automation is built are automatically covered.
• The Create Campaign step provides a human checkpoint for any access that wasn’t automatically revoked.

​

Testing

​

Unused access cleanup

​

What you’ll build

​

Setup

1. Navigate to the Salesforce application page, go to the Controls tab, and find the Unused access section. Click Add automation and select Create a custom usage-based automation from scratch. Alternatively, create a global automation with the Unused Access trigger and select Salesforce as the app.
2. Configure the trigger:
   • App name: Salesforce
   • Days since last login: 30
   • Cold start behavior: Only newly unused. This prevents the automation from immediately acting on all currently-inactive accounts when first published. Only accounts that cross the 30-day threshold after the automation goes live will trigger it.
3. Add a Send Email step. Set the recipient to the subject user and the message to:

Your Salesforce access has been unused for 30 days. If you still need this access, log in within the next 14 days. Otherwise, your access will be automatically revoked.

4. Add a Wait for Duration step. Set the duration to 14 days. During this time, the automation execution pauses. If the user logs in during this window, the access is no longer “unused,” but the automation execution still proceeds (the wait step does not re-check usage).
5. Add a Revoke Entitlements step. Select the user’s Salesforce entitlements.
6. Add a Send Slack Message step. Set the channel to #it-access and the message to:

Salesforce access revoked for {{ ctx.trigger.user.display_name }} ({{ ctx.trigger.user.email }}) due to 30+ days of inactivity.

​

Why these choices

• Cold start: “Only newly unused” avoids a flood of revocations on day one. If you have 200 dormant Salesforce accounts, you probably don’t want all 200 to get warning emails the moment you publish.
• The 14-day wait gives users a chance to log in before losing access. This reduces friction and support tickets.
• Building this as an app-scoped automation keeps it visible on the Salesforce application page, which is where an app admin would look for it.

​

Prerequisites

• The Salesforce connector must report last login data. Check the connector capabilities table to verify.
• If the connector doesn’t report login data, the Unused Access trigger will treat all accounts as unused.

​

Testing

​

Requestable: infrastructure provisioning

​

What you’ll build

​

Prerequisites

• A published Function that provisions the cloud environment and returns the environment URL and ID.
• An outbound webhook configured to call the environment cleanup API.
• Familiarity with requestable automations.

​

Setup

1. Create a new automation and select the On Demand trigger.
2. Make the automation requestable by following the setup in requestable automations. Configure the form with:
   • Environment type (dropdown): Development, Staging, Production-mirror
   • Justification (textarea): Why they need the environment
   • Duration (dropdown): 1 day, 3 days, 7 days
3. Set up a request policy requiring manager approval.
4. Add a Call Function step. Select your provisioning function. Pass the form inputs as parameters:

environment_type: ctx.trigger.form_fields.environment_type
requested_by: ctx.trigger.user.email

5. Add a Send Slack Message step. Notify the requester using the function’s output:

Your {{ ctx.provision.environment_type }} environment is ready!
URL: {{ ctx.provision.environment_url }}
This environment will be automatically deprovisioned in {{ ctx.trigger.form_fields.duration }}.

6. Add a Wait for Duration step. The duration should match the value from the form. If the form offers fixed options like 1/3/7 days, you can set the wait duration to match the longest option and use step conditions, or create separate automations per duration.
7. Add a Run Webhook step. Select your cleanup webhook and pass the environment ID:

{
  "environment_id": "{{ ctx.provision.environment_id }}",
  "action": "deprovision"
}

8. Add a Send Email step confirming the environment has been deprovisioned.

​

Why these choices

• On Demand is required for requestable automations. It ensures the workflow only runs when someone explicitly requests it.
• Form fields capture structured input that flows into the automation as ctx.trigger.form_fields, making the provisioning step dynamic.
• Function step handles the provisioning logic (API calls, resource creation) that built-in steps can’t do.
• Wait + webhook creates a time-boxed access pattern: provision, use, automatically clean up.

​

Testing

​

Scheduled compliance check

​

What you’ll build

​

Prerequisites

• A published Function that looks up when the user’s access was granted and returns { "days_active": <number>, "should_review": <Boolean> }.

​

Setup

1. Create a new automation and select the Schedule for App User trigger. Set the app to your production AWS account and the frequency to weekly.
2. Add a trigger condition to scope to contractors:

subject.employmentType == "CONTRACTOR"

3. Add a Call Function step (name it access_check). Select your function and pass the user and app context:

user_id: ctx.trigger.user_id
app_id: ctx.trigger.app_id

4. Add a Create Campaign step. Select a review template targeting the contractor’s AWS access. On the Advanced tab, add a step condition:

ctx.access_check.should_review == true

5. Add a Send Email step. Set the recipient to your compliance team. On the Advanced tab, add a step condition:

ctx.access_check.days_active > 90

Contractor {{ ctx.trigger.user.display_name }} has held AWS production access for {{ ctx.access_check.days_active }} days. A review campaign has been created.

​

Why these choices

• Schedule for App User (not Schedule for User) because you specifically want users of the AWS production app, not all users in the directory.
• The trigger condition filters to contractors before the automation runs any steps, avoiding unnecessary Function calls for full-time employees.
• Step conditions on Create Campaign and Send Email mean the automation runs for every contractor each week, but only takes action when the access duration threshold is exceeded. Steps that don’t meet their condition are silently skipped.
• Functions handle the date math and business logic that CEL alone can’t do (looking up grant dates, computing durations).

​

Testing

​

Other automation patterns