Salesforce User Offboarding in Winter ’27: A Checklist

Executive Summary

Salesforce user offboarding is two jobs that are easy to confuse: restricting login now, and resolving everything the departing person still owns or triggers. Salesforce's troubleshooting article for blocked deactivations, dated September 9, 2026, states that freezing "does not free up a license but prevents login right away" ^[1]. Deactivation can fail because a validation rule on the User object blocks the change ^[1], and afterward the user's records, owned folders and Chatter group memberships are not automatically reassigned ^[1]. Salesforce's own 2015 admin guidance says the same thing in different words: deactivation does not change ownership of the user's records ^[2]. A completed freeze is therefore not a completed offboarding ticket.

Winter '27 adds native AI to the first stage. The Salesforce Admins podcast page dated October 15, 2026 reports that Setup with Agentforce is generally available ^[3] and that admins can freeze and unfreeze groups of users ^[3]. The Setup agent always seeks confirmation before acting ^[4], and its bulk actions are limited to the User object. The pages reviewed for this report do not list deactivation as a bulk task, so this report treats it as not tested.

The recommended runbook has two stages. Stage one pins one immutable user ID, captures baseline status and restricts login under the organization's own policy. Stage two builds a dependency inventory, separates mandatory platform blockers from continuity risks, and records each proposed change in a handoff matrix with a named approver and a read-back check. An AI assistant can enumerate references and draft that matrix, but it must not choose who inherits a customer relationship. The Model Context Protocol (MCP) specification itself expects a human able to deny tool invocations ^[5], and Salesforce documents that its Beta Headless 360 server limits an agent to what the user could do anyway ^[6].

Limits to plan around: the Setup Audit Trail object exposes Setup changes for at least the last 180 days ^[7], so evidence should be exported at closure. No security standard read for this report sets one universal deadline, since NIST SP 800-53 leaves the disabling period to the organization ^[8]. No Salesforce org was available for this report, so "verified" means documented in a page opened on October 27, 2026, not tested live.

Introduction and Background

An administrator receives a message that a named employee has left. The request sounds simple, but it bundles four different outcomes: stop the person logging in, free a license, keep the business running, and leave evidence that all of it happened. Salesforce models these as separate mechanics. Trailhead states that both freezing and deactivating prevent the user from logging in ^[9], yet only one of them changes license availability, and neither moves a single record.

This report is written for Salesforce administrators, RevOps (revenue operations) leads and consulting partners offboarding a named human user. It does not cover bulk HR-driven deprovisioning, or guest, integration and Automated Process users. It targets Salesforce Winter '27, which ships API version 68.0 ^[10]. The official countdown listed production upgrade dates of September 4, October 2 and October 9 ^[11], and the developer blog described the final rollout as set for October 9, 2026 ^[10]. On the publication date, October 27, 2026, production orgs should therefore be on Winter '27, but each org's release and edition still need confirming; the countdown directs admins to Trust for sandbox windows ^[11].

The article answers the questions admins actually type: how to freeze a user, why a user cannot be deactivated, how freeze differs from deactivate, who should receive records, and what an offboarding checklist should contain. It also asks a narrower question about AI: where does an authorized assistant help, and where must a human decide? The working position is that AI materially speeds inventory and comparison work, while ownership decisions, approvals and verification remain human.

Sources are Salesforce Help and developer documentation, Trailhead, the Salesforce Admins blog, and independent security guidance. A third-party checklist from Salesforce Ben is used only to compare scope, not as an authority on platform behavior ^[12]. Salesforce's 2015 guidance already advised freezing first, because freezing a user locks their credentials ^[2], so the core idea is old. What is new in Winter '27 is the native AI surface around it.

Freeze, Deactivate, License and Ownership: Four Different Things

The UserLogin object reference defines the frozen state precisely: the user cannot log in, but the account is not deactivated ^[13]. Deactivation is a separate state change controlled by the Active flag on the User record, which the object reference describes as indicating whether the user has access to log in ^[14]. Users cannot simply be deleted, because deletion can result in orphaned records and the loss of critical business information ^[9].

Table 1 below separates the four outcomes that an offboarding ticket usually merges.

The table shows why the same ticket often fails review. A requester who sees "frozen" in the user list may believe the work is done, while the license is still consumed and the records still belong to the departed person. Salesforce Help states that freezing does not make user licenses available ^[17]. The practical rule is to treat freeze as the first control in a sequence, not as a closing state.

Deactivation also changes visibility. Deactivated users lose access to records shared with them ^[18], and managers normally see data owned by users below them in the role hierarchy ^[9], so an unplanned deactivation can change what a manager sees before any ownership transfer has happened.

Stage One: Identify the User and Restrict Login

Identify by immutable ID and capture a baseline

Names change and are duplicated; a Salesforce User ID does not. Pin every later query, transfer and evidence request to one User ID, and record the following before changing anything:

• Identity: User ID, username, profile, role and manager.
• Status: active flag, frozen flag, license, and permission set assignments.
• Activity: last login and recent history from Login History, captured with a timestamp.
• Instruction: the named source of the departure instruction (usually HR or the line manager), its date and time, and the intended successor.

Salesforce's 2015 guidance advises admins to know their IT department's termination process ^[2], because HR or IT often learns of a departure first. A missing successor is not a reason to delay the freeze; it is a reason to leave the matrix row open with an unresolved owner.

Emergency access restriction

Security guidance does not set one universal deadline. NIST SP 800-53 Rev. 5 leaves the period for disabling system access to the organization ^[8], and its guidance says organizations may consider disabling accounts of individuals who are being terminated ^[8]. The only numeric targets found are in federal facility guidance from CISA's Interagency Security Committee: 1 hour for high-risk separations ^[19], 4 hours for moderate risk ^[19] and 18 hours for low risk ^[19]. Those figures belong to that federal checklist, not to private Salesforce orgs, but they show that timing is usually tiered by risk, and the same guide says to remove access at an appropriate time based on risk ^[19]. The UK National Cyber Security Centre likewise suggests revoking administrator access promptly in case there is animosity around a departure ^[20], and asks that account management include joiners, movers and leavers processes so access can be revoked when no longer needed ^[21].

For an urgent case, follow the organization's escalation policy and have a second authorized administrator perform the freeze. The Salesforce Ben checklist makes a related point: create a new admin before freezing a departing admin ^[12], and its pitfalls guide opens with the same warning to have another admin ^[22].

What a freeze does and does not prove

Freezing is documented as blocking login. In the pages read it is not documented as ending sessions or revoking tokens, and Salesforce provides separate tools for those:

• Session Management: ending a session makes the user log in again, and token revocation can take up to 30 minutes in some cases ^[23].
• OAuth tokens: admins with the Customize Application permission can see all tokens for all users through the OauthToken object ^[24].
• Sessions as data: the AuthSession object represents an individual user session, so sessions can be inspected and ended programmatically ^[25].

The OAuth standard explains why the distinction matters. RFC 7009 requires support for revoking refresh tokens ^[26], but access-token revocation is only a SHOULD ^[26], and where it is unsupported, access tokens will not be immediately invalidated ^[26]; the RFC's other design option is short-lived access tokens ^[26].

NCSC's guidance for small organisations similarly says to remove or disable accounts that are no longer used ^[27]. The conclusion is deliberately narrow. After a freeze, record "login blocked" as verified, and record "sessions and tokens revoked" as a separate check backed by Session Management, OAuth usage and Login History evidence. Do not assert that a freeze revoked every session or token; CISA's insider-threat guidance notes that former employees may use prior insider knowledge to regain access ^[28].

Bulk freeze in Winter '27

Winter '27 adds a bulk path through the Setup agent, which the podcast describes as freezing a bunch of users and unfreezing a bunch of users ^[3]. Before that, the manual bulk route was Data Loader against the UserLogin object ^[13]. Treat the bulk path as a speed feature, not a safety feature: each user ID still needs its own row in the matrix.

Stage Two: Build the Dependency Checklist

Salesforce divides deactivation problems into things that stop the Active flag from clearing and things that keep working, or quietly stop working, afterward. This report labels the first group mandatory platform blockers and the second continuity risks. A blocker produces an error and forces a decision; a continuity risk produces silence.

Mandatory platform blockers

The Help article reviewed here names an active validation rule on the User object as the most common cause, and lists the Default Workflow User, Default Lead Owner, Default Case Owner, approval process approvers and workflow email alert recipients as references that block deactivation ^[1]. Related knowledge articles add specifics:

• Case rules: Salesforce Ben advises removing the user from any lead or case assignment rules ^[22], and a user receiving cases from assignment or escalation rules triggers "You cannot deactivate a user who is receiving cases or notifications" ^[29].
• Web-to-Lead: the default creator triggers its own message, "You cannot disable the Web to Lead default creator" ^[30].
• Custom hierarchy field: the user cannot be deactivated while selected in such a field, even if the field is deleted ^[16], and Trailhead names the same case as a reason to freeze instead ^[18].

Table 2 below classifies the dependencies read for this report and gives a place to start looking.

Read the table as a triage order. Blockers must be cleared before the Active flag will save; continuity risks need an explicit decision even though the save would succeed.

Continuity risks

Ownership is the largest risk. Salesforce recommends transferring ownership first when a user owns more than 10,000 records of one object ^[16]. Salesforce Ben likewise advises that records should not be owned by an inactive user ^[12].

Scheduled work is next:

• Reports: a scheduled report does not run if its running user becomes inactive ^[31].
• Dashboards: a dashboard running as a deactivated user may give unexpected results. This report cites no Salesforce page for that behavior, so check each dashboard's running user in the org.
• Data Export: the weekly export fails if the user who scheduled it is deactivated ^[32].
• Flow interviews: paused interviews cannot be resumed if the interview owner is deactivated ^[33], so deactivate only after waiting interviews are cleared.
• Inventory starting point: the CronTrigger object can be queried for scheduled jobs ^[34], and the Scheduled Jobs page in Setup shows who submitted each one.

The documentation read for this report does not state what happens to a scheduled Apex job when its scheduler is deactivated, so that item belongs in the sandbox regression checklist rather than in an assumption.

Integrations are the third risk. The Salesforce Ben checklist recommends an integration user rather than a named admin's credentials ^[12], advises changing the running user of scheduled jobs to an active account ^[12], and notes that only the person who last edited a flow is notified of its errors ^[12]. Metadata can reveal Salesforce-side references, but it cannot reveal credentials held inside a third-party system or which external sessions remain open.

Cleanup comes last: package licenses can remain assigned to inactive users ^[35], and permission set assignments should be reviewed.

AI-Assisted Evidence Gathering, Read-Only First

AI changes inventory work more than decision work. The inventory is large, spread across Setup areas, and tedious to compare by hand. Deciding who now owns a customer relationship is a business judgment. The runbook therefore lets an authorized assistant collect and organize evidence, and keeps successor selection with a named human.

Native option first: Setup with Agentforce

Setup with Agentforce is the native route. The Admins blog says it only assists with tasks for which the requestor has the correct permissions ^[4] and always seeks confirmation before acting ^[4], and Help adds that it makes no changes without approval ^[36]. Its changes can be tracked in the Setup Audit Trail ^[4]. Bulk actions are available only for the User object ^[37]. Prerequisites are material: the general-availability post says to enable Agentforce and Data 360 in the org ^[38], and availability is edition-dependent.

Two source discrepancies deserve attention:

• Data 360: the October 15 podcast says Data 360 is no longer required ^[3], while a later Winter '27 release note says it is again a prerequisite in the enablement process ^[39].
• Editions: the introductory post lists Enterprise, Performance, Unlimited and Developer editions with Foundations or Agentforce 1 ^[4], while the sibling freeze note lists Professional, Performance and Unlimited ^[40].

Verify both in the target org rather than picking a source.

Where hosted MCP fits, proportionately

Salesforce also publishes hosted MCP servers. They use per-user OAuth 2.0 so agents operate with appropriate permissions ^[41], and field-level security, object permissions and sharing rules apply to every tool call ^[42]. The Headless 360 server is a Beta service ^[6]; its documentation lists user management, including deactivating and freezing, as a use case ^[6], and recommends configuring the client to require approval before tools that change org configuration ^[6]. Third-party admin MCP servers, including one from Cirra AI, the publisher of this report, occupy the same category: another permission-bound interface to the same org, used with the same approval and sandbox discipline. This report did not test any MCP server's offboarding coverage and makes no tool-coverage claim.

Table 3 below records capability states by interface. Verified means documented in a Salesforce page cited in that cell. Documented elsewhere in this report means the cell carries no citation of its own, but the action is documented in a Salesforce page cited in the text above or below. Not tested means no such documentation was read and no org test was run. Unsupported means a page explicitly says so.

The table is intentionally sparse. Many cells read "Not tested" because the sources describe user management at feature level rather than listing every operation, and because no live org was available. An assistant is useful for evidence collection today; any write capability must be confirmed by a sandbox run before it enters a production ticket. A "Verified" Setup with Agentforce cell also does not mean the agent performed an entire offboarding, only that the specific action is documented.

A read-only evidence request

Start the assistant in a session that cannot write, and say so in the request:

Scope: User ID <18-character ID>. Read-only. Do not create, update, delete,
freeze, deactivate or transfer anything.
Collect: validation rules on User that reference IsActive; Default Workflow
User, Default Lead Owner, Default Case Owner, Web-to-Lead default creator;
approval processes naming this user; assignment and escalation rule entries;
custom User hierarchy fields set to this user; queues and groups; owned
records by object with counts; scheduled jobs, reports and dashboards with
this user as running user; flows referencing this user; connected app and
OAuth entries for this user.
For every item return: API name or Setup path, record ID, retrieved timestamp,
blocker or continuity risk, and what you could NOT see.
Finish with a proposed action list. Do not propose a successor for customer
relationships; mark them "owner needed".

The required outputs are metadata or API names, a retrieved timestamp, explicit gaps and a proposed action list. The "could NOT see" line matters most. MCP tool annotations such as a read-only hint say a tool does not modify its environment ^[44], but the schema also says annotations are not guaranteed to describe the tool faithfully ^[44], so enforce read-only behavior through permissions and client configuration, not through hints.

Comparison with manual Setup inspection

Manual inspection is slow but legible. Salesforce Ben notes that Salesforce reports only one blocking error per attempt ^[22], so trial and error exposes blockers one at a time. An assistant can enumerate in one pass, which is the real gain. Its view is bounded by the connected user's permissions, as Salesforce states for its own servers ^[42]. Metadata visibility is not visibility into third-party systems: an external API key used in a callout, a vendor dashboard logged in with the departed user's email, or a partner portal account will not appear in a metadata query. Record those as "unknown, owner to confirm" rather than "none found".

Clear Approved Dependencies, Deactivate and Verify

Why blanket validation-rule disabling is a poor default

The Salesforce article describes deactivating blocking validation rules temporarily, then re-enabling them or editing them to exclude the deactivation scenario using ISCHANGED on the Active field ^[1]. The edit is the safer default for three reasons:

• Scope: disabling a rule is org-wide, so every other edit it protects goes unvalidated while it is off.
• Restoration: re-enabling depends on a person remembering to do it.
• Visibility: an unrestored rule can sit unnoticed unless the restoration is a checked ticket item.

If an exception is genuinely necessary, document its scope and restoration: which rule, which environment, who approved, start and end times, and the read-back proving the rule is active again. Salesforce Ben flags a more specific cause, a validation rule that names the admin's username or ID ^[22]; fix the hard-coded reference rather than turning the rule off.

Clear only approved rows

Work from the handoff matrix, one approved row at a time. Each write proposed by an assistant carries an approver and a read-back check. The MCP specification supports this pattern: show tool inputs to the user before calling the server ^[5], prompt for confirmation on sensitive operations ^[5], and log tool usage for audit purposes ^[5]. Requested scopes should follow least privilege ^[45].

For ownership, choose the tool by volume:

• Up to 250 records: Mass Transfer; larger transfers use Data Loader or another tool ^[46].
• Bulk by object: a knowledge article states that some objects cannot be transferred in bulk with Mass Transfer and must use Data Loader ^[47]. That appears to conflict with the Mass Transfer page, which lists accounts and related items, so treat it as an object-level limit.
• Data Loader method: export the records with Owner ID, replace the values with the new owner's User ID, and update.
• Inactive owners: moving a record to or from an inactive user needs a dedicated permission, which is why transferring before deactivation is simpler.
• Manual shares: Winter '27 adds a setting to keep manual shares when transferring records ^[3]; review it with the data owner before bulk moves.

Deactivate with approval and verify actual status

Deactivation is a single change: clear the Active flag. Do not accept the absence of an error as evidence. Query the User record and confirm Active is false, confirm the UserLogin state, and record the license status. If deactivation still fails, work through the documented list instead of guessing, and keep the freeze in place as the stopgap.

Validate the Handoff Under the Successor's Real Access

A transfer is not finished when OwnerId changes. The successor may lack object permissions, field access, sharing or queue membership that the departed user had. The data of a deactivated user can still be transferred to other users ^[18], but visibility afterward depends on the new owner's role and sharing. Account transfers can also change sharing, so the new owner's access has to be checked, not assumed.

Validate with the successor's real access, using the organization's approved test-user method:

• Records: transferred accounts and open opportunities appear in the successor's list views.
• Routing: a test case routes to an active owner or queue.
• Approvals: a test approval request reaches the replacement approver.
• Notifications: each email alert recipient that formerly pointed at the departed user receives a test message.
• Scheduled work: reports, dashboards and exports run under their new running user.

Auditors may look for evidence that continuing duties are identified and enforced ^[48], so attach read-back evidence to each row: a before and after value, a timestamped query result or screenshot, and the person who confirmed it. The CISA separation checklist also asks that all records related to the separation be properly documented ^[19]. Export Setup Audit Trail history at closure, because it is retained for at least the last 180 days ^[7]. Winter '27 also makes User Field History Tracking generally available ^[49] and auto-enabled ^[49], though admins still choose which fields to track. NIST notes that audit records are retained until they are no longer needed for administrative, legal, audit or operational purposes ^[8]. Unresolved items stay on the ticket with a named owner and date.

Data Analysis and Evidence

This report is analytical rather than empirical: no source read publishes time savings for offboarding, and none are claimed. The measurable facts are limits, retention windows and counts taken from documentation.

• Volume thresholds: the 250-record Mass Transfer run and the 10,000-record guideline are cited in the ownership sections above; SOQL (Salesforce Object Query Language) statements also cannot exceed 100,000 characters by default ^[50], which limits very long OwnerId filter lists.
• Retention windows: the Setup Audit Trail object covers at least the last 180 days ^[7]; token revocation after a session ends can take up to 30 minutes, as cited above.
• API capacity: Salesforce's Enterprise Edition worked example is 115,000 requests per day ^[51], and the limit is org-wide, so a read-heavy evidence pass shares a pool with integrations.
• Security timing references: the federal ISC checklist uses 1, 4 and 18 hours by risk tier, as noted above; NIST leaves the period organization-defined; CIS Safeguard 6.2 calls for disabling accounts immediately upon termination, rights revocation or role change ^[52], and for disabling rather than deleting where audit trails must be preserved ^[52].
• Scope comparison: the Salesforce Ben checklist cited above is a third-party scope reference; the matrix in this report adds release-specific evidence and action gates, but its value as a planning aid is untested.
• Review cadence: the NCSC suggests reviewing who has access to important accounts every few months ^[27], which makes a recurring sweep of inactive and frozen users a natural companion to the runbook.
• Remaining work: count unresolved matrix rows only. A row is unresolved when its status is not closed, its read-back evidence is missing, or its owner is blank. That number is the organization's own data, not a benchmark.

The Ticket Template and Sandbox Regression Checklist

Handoff matrix columns

The reference asset is a spreadsheet or ticket table with one row per dependency:

user_id | dependency | source_or_record_id | blocker_or_continuity_risk |
proposed_successor | approver | before | after | validation_evidence |
unresolved_owner

The following is a Hypothetical Example, not a real case. The user ID is a placeholder. The dependency is "Default Case Owner", sourced from the Support Settings page and classed as a mandatory blocker. The proposed successor is a support queue and the approver is the support operations lead. The before value shows the departed user, the after value shows the queue, the evidence is a timestamped screenshot plus a routed test case, and the unresolved owner is blank.

Reusable ticket template

OFFBOARDING TICKET: <user name> / User ID <ID>
Org / release / edition verified: <org ID, Winter '27, edition, date>
Departure instruction: <source, date, time>
Intended successor(s): <names or "owner needed">

STAGE 1
[ ] Baseline captured (active, frozen, profile, role, last login)
[ ] Login restricted (method, approver, timestamp)
[ ] Sessions and tokens reviewed separately (Session Management, OAuth usage)
[ ] Emergency escalation used? <yes/no, policy reference>

STAGE 2
[ ] Evidence request run read-only (tool, timestamp, gaps listed)
[ ] Handoff matrix complete; every write has approver + read-back
[ ] Blockers cleared (list)
[ ] Validation-rule exception? <scope, window, restoration proof or "none">
[ ] Deactivated by <name>; status read back (Active=false, license state)
[ ] Ownership validated under successor access
[ ] Audit Trail and matrix exported (within 180 days)
Unresolved items: <count, owners, dates>

Sandbox regression checklist

Before relying on any AI-assisted write path, rehearse in a sandbox:

• Blocked user: one user with a User validation rule, a default case owner and an approval reference.
• Scheduled work: one user with a scheduled report and, if used, a scheduled Apex job.
• Narrow successor: one record transfer to a successor with narrower access.
• Release hygiene: Salesforce advises against deploying from a preview sandbox straight into non-preview production ^[53], and the same post series stresses checking which release a sandbox is on. Re-run the checklist after each seasonal release.

Implications and Future Directions

Winter '27 shortens the first stage but not the second. Native bulk freeze reduces clicks for departures that arrive in batches, and Setup with Agentforce, with its approvals and audit trail, is a reasonable first AI surface for admins. The dependency work still depends on org-specific configuration, and the discrepancies on Data 360 and editions mean preparation should include a pre-flight check.

Offboarding is a good test case for AI-assisted administration because every step is checkable. NIST account management calls for accounts to be created, enabled, modified, disabled and removed under defined procedures ^[8], and PS-4 expects termination of authenticators and credentials ^[8] and retention of access to information formerly controlled by the individual ^[8]; a handoff matrix is one way to show both. The OWASP testing guide asks what happens to a de-provisioned user's resources, whether they are deleted or access is transferred ^[54], and whether de-provisioning requests are verified and authorized ^[54]. The NCSC cloud principles tie authentication to joiner, mover and leaver processes ^[55] and aim to reduce the likelihood of leavers retaining functional credentials ^[55], and Australia's ACSC says to give administrative access only to staff who need it (Source: www.cyber.gov.au) and to remove it when staff leave (Source: www.cyber.gov.au).

For tooling, expect more permission-bound interfaces. Salesforce's Beta Headless 360 server sits beside the DX MCP server, which Salesforce describes as including over 60 tools ^[56] aimed at development rather than user administration. Third-party admin servers will fit the same model. None removes the need for human approval, and identity-governance practice points the same way: audit trail and object history capabilities can be used to examine privileges before termination ^[57], terminated users can be moved to an archived lifecycle state ^[57], and ISO 27001 control A.6.5 is summarized as requiring companies to define which security duties remain valid after a person leaves ^[48].

Open questions remain: how deactivation interacts with Apex scheduled jobs, whether the Setup agent will gain deactivation, and whether freezing will be documented as ending sessions. Each should be tested rather than assumed. Separate attributable accounts for staff with administrative privileges (Source: www.cyber.gov.au) also make offboarding administrators simpler.

Frequently Asked Questions (FAQs)

How to freeze a user in Salesforce? Open the user in Setup and click Freeze, which prevents the user from logging in ^[17]. At scale, use Data Loader on UserLogin ^[13] or, in Winter '27, the Setup agent's bulk action.

What is the difference between freeze and deactivate? Both block login ^[9]. Only deactivation makes the license available, and neither reassigns records.

Why can't a Salesforce user be deactivated? Check the User validation rule, Default Workflow User, Default Lead Owner, Default Case Owner, approvers and hierarchy fields, as listed in the blockers section.

Who should get the records when a user leaves? A named business owner, approved in the matrix. Ownership does not move on deactivation.

Is there a Salesforce offboarding checklist? The two stages and tables above form one; Salesforce Ben publishes a seven-step admin variant.

What are the best practices for deactivation? Freeze first, clear approved blockers, transfer large ownership sets before deactivating, verify actual status and export evidence.

Conclusion

The main finding is simple: freezing and deactivating solve different problems, and neither solves record ownership. Salesforce's September 9, 2026 troubleshooting article is clear that a frozen user still consumes a license and that records are not reassigned automatically. A two-stage runbook keeps those facts visible: restrict login by user ID under the organization's policy, then resolve blockers, assign owners and verify under the successor's real access.

Winter '27 gives admins a native AI option for the first stage, with approval and an audit trail, and a growing set of permission-bound interfaces for evidence collection. The same sources leave gaps: deactivation is not listed among the bulk tasks read, freezing is not documented as revoking sessions, and several documentation details conflict. The disciplined use of AI is therefore bounded: let it enumerate and draft, let named humans approve, and let read-back evidence close the ticket. Whatever remains unresolved belongs on the ticket with an owner and a date.