From c896f2f87d886993e22b7694f3a0930615cac6ec Mon Sep 17 00:00:00 2001 From: Mindy Moreland Date: Thu, 9 Apr 2026 16:10:40 -0700 Subject: [PATCH] docs(google-workspace): add example automations for connector actions Adds an onboarding and offboarding workflow example showing how to sequence connector actions in C1 automations, with example field values for each step. Co-Authored-By: Claude Sonnet 4.6 --- baton/google-workspace.mdx | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/baton/google-workspace.mdx b/baton/google-workspace.mdx index 2eda7dcb..1916f801 100644 --- a/baton/google-workspace.mdx +++ b/baton/google-workspace.mdx @@ -59,6 +59,38 @@ The synced user profile exposes the job title under both `title` and `job_title` `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. +### 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.