HOLD FOR MERGE Update automations-steps-reference.mdx

product/admin/automation-examples.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Automation examples"
 description: "End-to-end walkthroughs for common automation patterns including onboarding, offboarding, unused access cleanup, and more."
 sidebarTitle: "Automation examples"
 ---
 
@@ -39,7 +39,7 @@
 
 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:
 ```
@@ -60,7 +60,7 @@
 
 ---
 
 ## Employee offboarding
 
 **Use case:** When a user's status changes to disabled, revoke their access, update their ConductorOne status, and notify the security team.
 
@@ -83,7 +83,7 @@
 ```go
 ctx.trigger.oldUser.status == "ENABLED" && ctx.trigger.newUser.status == "DISABLED"
 ```
    This is important: checking only `newUser.status == "DISABLED"` would also fire if other attributes change on an already-disabled user. Using both oldUser and newUser ensures you only catch the actual status transition.
 
 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).
 
@@ -171,7 +171,7 @@
 
 ---
 
 ## Requestable: infrastructure provisioning
 
 **Use case:** Engineers request a temporary cloud sandbox through the self-service catalog. The request requires manager approval, calls a Function to provision the environment, and auto-revokes after the requested duration.
 
@@ -179,14 +179,14 @@
 
 | Component | Configuration |
 |---|---|
 | Trigger | On Demand (requestable) |
 | Form fields | Environment type (dropdown), Justification (textarea), Duration (dropdown) |
 | Approval | Manager approval via request policy |
 | Step 1 | Call Function -- provision the environment |
 | Step 2 | Send Slack Message -- notify requester with environment details |
 | Step 3 | Wait for Duration -- requested duration |
 | Step 4 | Run Webhook -- call cleanup API |
 | Step 5 | Send Email -- confirm environment deprovisioned |
 
 ### Prerequisites
 
@@ -198,9 +198,9 @@
 
 1. Create a new automation and select the **On Demand** trigger.
 
 2. Make the automation requestable by following the setup in [requestable automations](/product/admin/automation-actions). 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.
@@ -218,7 +218,7 @@
 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:
 ```json
@@ -228,18 +228,18 @@
 }
 ```
 
 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
 
 Test the requestable automation as described in the [requestable automations](/product/admin/automation-actions) docs. Submit a test request, approve it, and verify the full flow: provisioning, notification, wait, cleanup.
 
 ---
 
@@ -253,9 +253,9 @@
 |---|---|
 | Trigger | Schedule for App User (app: AWS Production, weekly) |
 | Condition | `subject.employmentType == "CONTRACTOR"` |
 | Step 1 | Call Function -- check access duration, return days_active and should_review |
 | Step 2 (conditional) | Create Campaign -- if should_review is true |
 | Step 3 (conditional) | Send Email -- if days_active > 90, alert compliance |
 
 ### Prerequisites
 
@@ -309,6 +309,58 @@
 
 ---
 
+## New account provisioning with initial password
+
+**Use case:** When a new employee account is created in a self-hosted application, automatically generate a password, set it on the account, and deliver it securely to the user's manager via a one-time secret link.
+
+<Note>
+The **Set credential** step used in this example is only supported for self-hosted connectors.
+</Note>
+
+### What you'll build
+
+| Component | Configuration |
+|---|---|
+| Trigger | Account Created |
+| Condition | Filter to the target application |
+| Step 1 | Generate password -- custom policy |
+| Step 2 | Set credential -- apply to the new account |
+| Step 3 | Store credential -- Paper Vault, deliver to manager |
+
+### Setup
+
+1. Create a new automation and select the **Account Created** trigger. Set the app to the self-hosted application where accounts are created.
+
+2. Add a **Generate password** step (name it `initial_password`). Select **Custom password policy** and configure length and character requirements to match the application's password rules.
+
+3. Add a **Set credential** step. Select the self-hosted connector for your application. Set the target account to:
+```
+ctx.trigger.app_user_id
+```
+Set the credential to the output of the previous step:
+```
+ctx.initial_password.credential_ref
+```
+
+4. Add a **Store credential** step. Set the credential to `ctx.initial_password.credential_ref`. Select **Paper Vault** as the vault type and set the recipient to the new user's manager:
+```
+ctx.trigger.user.manager_id
+```
+Set auth type to **SSO Internal** so the manager must authenticate before retrieving the secret. Leave max views at **1** so the link self-destructs after the manager retrieves it.
+
+### Why these choices
+
+- **Account Created** fires after the connector syncs the new account, so the account exists and can receive a credential by the time the Set credential step runs.
+- **Custom policy** on Generate password lets you match the target application's password complexity requirements. Use **Random 32-character** only if the application accepts any password format.
+- **Paper Vault with max views: 1** ensures the password is delivered once and then destroyed. The manager can share it with the employee directly, rather than the automation sending credentials over an unsecured channel.
+- **Delivering to the manager** (not the user directly) follows a common security pattern: a second person handles the credential handoff, creating an implicit acknowledgment step.
+
+### Testing
+
+Create a copy with an **On Demand** trigger. Run it manually, selecting a test account in the target application. Verify that the password is set on the account, and that the manager receives a Paper Vault link that works once and then expires.
+
+---
+
 ## Other automation patterns
 
 These patterns follow similar structures to the examples above. They are listed here as starting points rather than full walkthroughs.

product/admin/automations-steps-reference.mdx

@@ -120,11 +120,11 @@
 
 ## Remove access profiles
 
 Unenrolls a user from one or more access profiles, stopping automatic access provisioning from those profiles.
 
 | Field | Required | CEL | Notes |
 |---|---|---|---|
 | Target user | Yes | Yes | The user to unenroll |
 | Access profiles | Yes | No | Select specific profiles, or "all" |
 
 ---
@@ -149,7 +149,7 @@
 | Automation name | Yes | No | The target automation (must use an **On demand** trigger) |
 | Context | No | Yes | JSON data to pass to the child automation |
 
 ### Passing context to child automations
 
 The optional **Context** field lets you pass data from the current automation to the child. The context must be valid JSON. Use `{{ }}` template syntax to include dynamic values:
 
@@ -157,7 +157,7 @@
 {
   "user_email": "{{ ctx.trigger.user.email }}",
   "department": "{{ ctx.trigger.newUser.department }}",
   "source_automation": "offboarding-v2"
 }
 ```
 
@@ -170,7 +170,7 @@
 **Error behavior:** Fails if the target automation doesn't exist or isn't published. The parent automation does not wait for the child to complete; it proceeds to the next step immediately.
 
 <Tip>
 When debugging chained automations, check execution history on both the parent and child automations separately. The parent's log shows that the **Run automation** step succeeded (meaning it triggered the child), but you need to check the child's execution history to see if the child's steps succeeded.
 </Tip>
 
 ---
@@ -236,8 +236,8 @@
 | App type | Common actions |
 |---|---|
 | Active Directory | Lock account, unlock account, reset password, disable account |
 | Okta | Suspend user, unsuspend user, clear user sessions |
 | Google Workspace | Suspend user, unsuspend user |
 | AWS | Disable access keys, remove console access |
 
 The specific field requirements vary by action. After selecting an action, the step form displays the fields required for that action.
@@ -298,6 +298,57 @@
 ctx.risk_check.should_review == true
 ```
 
 For a full walkthrough of building Functions and using them in automations, see [using Functions in automations](/product/admin/functions-automations).
 
 **Error behavior:** Fails if the Function throws an unhandled error or exceeds its execution timeout. The error message from the Function is visible in the execution log. Debug Function errors in the Functions UI, which has its own invocation logs.
+
+---
+## Generate password
+
+Generate a random password using either a preset 32-character random password or a custom policy.
+
+| Field | Required | CEL | Notes |
+|---|---|---|---|
+| Password type | Yes | No | **Random 32-character password**: generates a random 32-character password with no additional configuration. **Custom password policy**: exposes the fields below. |
+| Length | Yes (Custom) | No | Minimum and/or maximum character length for the generated password. |
+| Character requirements | Yes (Custom) | No | Which character types must be included: uppercase, lowercase, numbers, special characters. |
+| Character rules | No (Custom) | No | Additional constraints on special characters: define a custom set of allowed special characters, or specify characters to exclude from the generated password. |
+| Step name | Yes | No | Used to reference this step's output in subsequent steps via `ctx.{step_name}`. |
+| Skip condition | No | Yes | If the expression evaluates to true, this step is skipped. |
+
+---
+
+## Set credential
+
+Apply a credential to a user's account in a connected application.
+
+<Note>
+**Set credential is only supported for self-hosted connectors.** Cloud-hosted connectors do not support credential actions.
+</Note>
+
+| Field | Required | CEL | Notes |
+|---|---|---|---|
+| Connector | Yes | No | Only connectors that support credential actions appear in the picker. |
+| Target account | Yes | Yes | The account to set the credential on. Accepts `ctx.trigger.app_user_id` or a CEL expression resolving to a C1 app user ID. For new accounts, pass the output of the Create account step. |
+| Credential | Yes | No | Reference to the Generate password step output: `ctx.{generate_step_name}.credential_ref`. |
+| Skip condition | No | Yes | If the expression evaluates to true, this step is skipped. |
+
+---
+
+## Store credential
+
+Store a generated credential in a ConductorOne vault and optionally deliver it to a recipient.
+
+| Field | Required | CEL | Notes |
+|---|---|---|---|
+| Credential | Yes | No | Reference to the Generate password step output: `ctx.{generate_step_name}.credential_ref`. |
+| Vault type | Yes | No | **Paper Vault**: one-time secret link, self-destructs after N views or a time window. **App Vault**: persistent, entitlement-bound storage accessible via VaultOpenerService. |
+| Recipient | Yes | Yes | C1 user ID or CEL expression. Use `ctx.trigger.user.manager_id` to deliver to the subject user's manager. |
+| Auth type | Yes (Paper Vault) | No | How the recipient authenticates to retrieve the secret. Options: SSO Internal, Email verified. |
+| Expiry | No (Paper Vault) | No | How long the secret is available before auto-expiration. Default: 72 hours. |
+| Max views | No (Paper Vault) | No | Number of times the secret can be viewed before it self-destructs. Default: 1. |
+| App | Yes (App Vault) | No | The application this credential belongs to. |
+| Entitlement | Yes (App Vault) | No | The entitlement that controls access. Users with this grant can retrieve the credential. |
+| Expiry | Yes (Paper Vault) | No | Auto-expire the credential after this duration. Expired credentials are tombstoned for audit. |
+| Skip condition | No | Yes | If the expression evaluates to true, this step is skipped. |
+