docs(approvals): name Set Manager and the admin endpoints as the in-product writers of sys_user.manager_id

The capabilities overview said no Console field, data-API write or auth admin
endpoint sets the column; the Set Manager row action and
POST /api/v1/auth/admin/set-user-manager do, and the admin bulk import reads a
manager_id column. The callout now names them, keeps provisioning as the bulk
path, and states the unset case the way the runtime decides it: the node's
onEmptyApprovers policy, by default admin_rescue.

The automation guide's manager callout said the admin bulk import does not
write the column; it does, through the same refusals as the endpoint, so that
clause is replaced by what the import does.

Claude-Session: https://claude.ai/code/session_01Q7Fy4uVkvBWgj9CLihdATJ
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

content/docs/automation/approvals.mdx

@@ -90,12 +90,18 @@ manager, close a cycle in the reporting chain, run past the chain depth cap, or
 who is provably outside every organization the user belongs to — each with the reason in the
 response. It is platform-admin gated, like every other `/api/v1/auth/admin/*` route.
 
+For many users at once, the admin bulk import (`POST /api/v1/auth/admin/import-users`) reads a
+`manager_id` column holding the manager's email address (or phone number, where phone sign-in is
+enabled) — someone in the same file or an existing user. It links each row once every row in the
+file exists, through the same refusals as the endpoint above, and reports each outcome on the
+row's `manager` result: a link it cannot make never fails the user it imported.
+
 The column is also written by a seed, or by any other system-context write, which bypasses the
 managed-update whitelist. SCIM provisioning and directory sync can populate it too, but only
 through a provisioning path your own deployment supplies: this platform declares the SCIM
-`manager` attribute without projecting it onto the column, and its admin bulk import does not
-write it either. Where an identity carries `source: 'idp_provisioned'` the admin operation
-**refuses**, so that directory stays the one surface that authors its manager.
+`manager` attribute without projecting it onto the column. Where an identity carries
+`source: 'idp_provisioned'` the admin operation **refuses**, so that directory stays the one
+surface that authors its manager.
 
 Setting the column is still something you have to *do*. Where `manager_id` is unset the rung
 expands to nobody, the request opens on a slate no one can act on, and under the default

content/docs/capabilities/approvals.mdx

@@ -9,17 +9,18 @@ Discounts, contracts, spend — anything that needs a human "yes" becomes an app
 
 ## Who approves — seven resolution styles
 
-A specific person · everyone holding a position (e.g. sales managers) · the submitter's direct manager (needs a provisioned reporting chain — see below) · a team · a department (optionally including sub-departments) · organization leadership · **a person named on the record itself** (e.g. the "regional director" field).
+A specific person · everyone holding a position (e.g. sales managers) · the submitter's direct manager (needs each user's manager set — see below) · a team · a department (optionally including sub-departments) · organization leadership · **a person named on the record itself** (e.g. the "regional director" field).
 
 <Callout type="warn">
-**Routing to the submitter's manager needs a reporting chain you provide.** Unlike a position you
-staff, a team you add people to, or a field you name on the record, this style does not get its
-data from inside the product: it resolves `sys_user.manager_id`, and no Console field, data-API
-write or auth admin endpoint sets that column. Your own provisioning fills it — a seed or other
-system-context write, or a SCIM / directory-sync path your deployment supplies. Until it is
-filled, a manager-only approval step resolves to nobody and the request waits. The exact remedy,
-and the fallback that needs no provisioning at all, are in
-[Automation → Approvals](/docs/automation/approvals).
+**Routing to the submitter's manager needs each user's manager set.** This style resolves
+`sys_user.manager_id`, which is not a profile field: editing the user does not set it. A platform
+admin sets it one user at a time from **Setup → Users → ⋯ → Set Manager**, which calls
+`POST /api/v1/auth/admin/set-user-manager`. For many users at once, provisioning fills it: the
+admin bulk-import endpoint reads a `manager_id` column, and a seed, or a SCIM / directory-sync
+path your deployment supplies, can write it too. Until it is set, a manager-only approval step
+resolves to nobody and the node's `onEmptyApprovers` policy decides what happens — by default the
+request opens and waits for an administrator. The details, and the fallback that needs no manager
+data at all, are in [Automation → Approvals](/docs/automation/approvals).
 </Callout>
 
 ## How it passes — four decision modes