WIP add example automations for connector actions

baton/google-workspace.mdx

@@ -2,7 +2,7 @@
 title: "Set up a Google Workspace connector"
 og:title: "Set up a Google Workspace connector"
 description: "C1 provides identity governance and just-in-time provisioning for Google Workspace. Integrate your Google Workspace instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for Google Workspace. Integrate your Google Workspace instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Google Workspace"
 ---
 
@@ -29,27 +29,27 @@
 
 ### Connector actions
 
 Connector actions are custom capabilities that extend C1 automations with app-specific operations. You can use connector actions in the [Perform connector action](/product/admin/automations-steps-reference#perform-connector-action) automation step.
 
 | Action name | Additional fields | Description |
 |-------------|-------------------|-------------|
 | update_user_status | `resource_id` (string, required)<br/>`is_suspended` (boolean, required) | Suspends or activates a user account |
 | disable_user | `user_id` (string, required) | Suspends a user account (idempotent) |
 | enable_user | `user_id` (string, required) | Unsuspends a user account (idempotent) |
 | change_user_primary_email | `resource_id` (string, required)<br/>`new_primary_email` (string, required) | Updates a user's primary email address |
 | transfer_user_drive_files | `resource_id` (string, required)<br/>`target_resource_id` (string, required)<br/>`privacy_levels` (string, optional) | Transfers Google Drive ownership from one user to another. Accepts `private` or `shared` for privacy_levels |
 | transfer_user_calendar | `resource_id` (string, required)<br/>`target_resource_id` (string, required)<br/>`release_resources` (boolean, optional) | Transfers Google Calendar data from one user to another |
 | change_user_org_unit | `user_id` (string, required)<br/>`org_unit_path` (string, required) | Moves a user to a different organizational unit |
 | offboarding_profile_update | `user_id` (string, required)<br/>`archive_account` (boolean, optional) | Comprehensive offboarding: removes from GAL, clears recovery details, deletes addresses/phones, optionally archives |
 | sign_out_user | `user_id` (string, required) | Signs user out of all sessions and resets sign-in cookies |
 | delete_all_oauth_tokens | `user_id` (string, required) | Revokes all third-party app authorizations |
 | delete_all_application_passwords | `user_id` (string, required) | Deletes all app-specific passwords |
 | create_group | `email` (string, required)<br/>`name` (string, required)<br/>`description` (string, optional) | Creates a new Google Workspace group |
 | modify_group_settings | `group_key` (string, required)<br/>`allow_external_members` (boolean, optional)<br/>`allow_web_posting` (boolean, optional)<br/>`who_can_post_message` (string, optional)<br/>`message_moderation_level` (string, optional) | Update settings for an existing Google Group |
 | update_user_manager | `user_id` (string, required)<br/> `manager_email` (string, required) | Updates the manager relation for a user in Google Workspace. Updates the 'manager' entry in the user's Relations field |
 | update_user_profile | `user_id` (resource ID, required)<br/>`given_name` (string, optional)<br/>`family_name` (string, optional)<br/>`recovery_email` (string, optional)<br/>`recovery_phone` (string, optional)<br/>`department` (string, optional)<br/>`job_title` (string, optional)<br/>`cost_center` (string, optional)<br/>`employee_type` (string, optional)<br/>`employee_id` (string, optional)<br/>`manager_email` (string, optional)<br/>`custom_schemas` (JSON string, optional) | Applies a partial update to a user's profile using patch semantics (only the provided fields change). Supports name fields, recovery details, Employee Information attributes (department, job title, cost center, employee ID, employee type), the manager relation, and custom-schema attribute values. Custom-schema definitions must already exist in the Workspace tenant. At least one updatable field is required. One narrow exception: an `employee_id` change that reduces the number of external IDs on the account (clearing it, or consolidating duplicate entries down to the new value) uses a full-object update instead of a sparse patch (Google does not reliably shrink a repeated field via patch), which widens the read-modify-write window to the whole user for that specific call. An empty or invalid `manager_email` does not fail the call when another provided field is valid — see the partial-success note below. |
 | update_user | `user_id` (resource ID, required)<br/>`user_profile` (JSON string, required) | Updates a user's profile from a `user_profile` JSON object (keys: `given_name`, `family_name`, `recovery_email`, `recovery_phone`, `department`, `job_title`, `cost_center`, `employee_type`, `employee_id`, `manager_email`, `custom_schemas`). Consumed by C1 push rules for automated profile sync. Same partial-success behavior as `update_user_profile` for `manager_email`. |
 | make_admin | `user_id` (resource ID, required)<br/>`status` (boolean, required) | Promotes (`status=true`) or demotes (`status=false`) a user to/from super administrator |
 
 <Note>
 The synced user profile exposes the job title under both `title` and `job_title`, for backward compatibility. `update_user`'s `user_profile` JSON object accepts any of `job_title`, `jobTitle`, or `title` as the source key. `update_user_profile` has a fixed argument schema and only exposes `job_title` — pass the value under that key.
@@ -59,6 +59,38 @@
 `update_user_profile`/`update_user` never clear an assigned manager through this action (matching `update_user_manager`), so an empty or invalid `manager_email` is not applied — but unlike other invalid fields, it does not fail the whole call when at least one other provided field is valid. The response's `success: true` only means the call completed; check the `skipped_fields` return field (comma-separated, naming any provided field that wasn't applied and why) to detect this — a caller checking `success` alone will not be told that `manager_email` specifically was skipped.
 </Note>
 
+### Example automations
+
+The following examples show how to sequence connector actions for common Google Workspace workflows. Each action maps to a **Perform connector action** step in the C1 automation builder. For more information, see [Automation steps reference](/product/admin/automations-steps-reference#perform-connector-action).
+
+#### Employee offboarding
+
+This sequence revokes access, transfers data, and disables the account:
+
+| Step | Action | Fields |
+|------|--------|--------|
+| 1 | `sign_out_user` | `user_id`: departing user's email or ID |
+| 2 | `delete_all_oauth_tokens` | `user_id`: departing user's email or ID |
+| 3 | `delete_all_application_passwords` | `user_id`: departing user's email or ID |
+| 4 | `transfer_user_drive_files` | `resource_id`: departing user; `target_resource_id`: manager or archive account; `privacy_levels`: `shared` |
+| 5 | `transfer_user_calendar` | `resource_id`: departing user; `target_resource_id`: manager or archive account; `release_resources`: `true` |
+| 6 | `offboarding_profile_update` | `user_id`: departing user; `archive_account`: `true` |
+| 7 | `disable_user` | `user_id`: departing user's email or ID |
+
+Steps 1–3 should run before data transfer to ensure the user cannot access or modify files during the transfer. Set `archive_account: true` in step 6 if your organization retains archived accounts for compliance.
+
+#### Employee onboarding
+
+This sequence activates the account and places the user in the correct structure:
+
+| Step | Action | Fields |
+|------|--------|--------|
+| 1 | `enable_user` | `user_id`: new hire's email or ID |
+| 2 | `change_user_org_unit` | `user_id`: new hire; `org_unit_path`: for example, `/Engineering` or `/Sales` |
+| 3 | `update_user_manager` | `user_id`: new hire; `manager_email`: manager's email address |
+
+Use `enable_user` when accounts are pre-created in a suspended state (a common pattern for managing start-date access). The `change_user_org_unit` step ensures the user inherits the correct group policies and settings for their team.
+
 ## Before you begin
 
 This connector authenticates with a **service account and domain-wide delegation**, not per-user OAuth. Every call reaches Google as one service account impersonating a Workspace super admin.
@@ -397,7 +429,7 @@
 | `admin.directory.group.readonly` | Read and sync Google Groups |
 | `admin.directory.group.member` | Write. Manage group memberships, adding or removing users from groups |
 | `admin.directory.rolemanagement` | Write. Manage role assignments, granting or revoking roles |
 | `admin.directory.user` | Write. Provision and deprovision accounts, update user profiles and custom-schema values, and promote/demote super administrators |
 | `admin.reports.audit.readonly` | Sync usage events and admin events, used with continuous sync |
 | `admin.datatransfer` | Write. Transfer user data between Google accounts |
 | `admin.directory.group` | Write. Provision groups |
@@ -408,7 +440,7 @@
 </Tabs>
 
 <Warning>
 The write scopes let C1 provision and deprovision access. **If you don't want C1 to perform these tasks, use the read-only scope set.** Read-only still syncs users, groups, and roles, so it's sufficient when you use Google Workspace as your [directory](#set-google-workspace-as-your-c1-directory) and run access reviews.
 </Warning>
 
 ### Find your customer ID and primary domain
@@ -452,7 +484,7 @@
 <Step>
 Choose how to set up the new Google Workspace connector:
 
    - Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren't yet managed with C1)
 
    - Add the connector to a managed app (select from the list of existing managed apps)
 
@@ -604,7 +636,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the Google Workspace connector to. Google Workspace data should be found on the **Entitlements** and **Accounts** tabs.
@@ -648,7 +680,7 @@
 
 ## What's next?
 
 If Google Workspace is your company's identity provider (meaning that it is used to SSO into other software), the integration sync will automatically create applications in C1 for all of your SCIMed software. Before you move on, review the [Create applications](/product/admin/applications) page for important information about how to set up integrations with the SCIMed apps.
 
 ## Troubleshooting the Google Workspace integration