Role Hierarchy Restructure

Apply many UserRole changes from an artifact in one admin-approved manifest.

If the admin only asks which roles exist or how they are nested, hand off to

managing-roles

. Do not query, do not ask the step 0 questions, and do not submit.

Inputs

PDF org chart (text-selectable),
```
.xlsx
```
/
```
.csv
```
with
```
role_name
```
and
```
parent_role_name
```
(empty parent = top-level), or plain text with one
```
Role: Parent
```
pair per line.
Or a pre-parsed list of
```
{roleName, parentRoleName}
```
objects.
Optional mapping hints when a chart name is not the org's
```
Name
```
or
```
DeveloperName
```
.

Flow

0. Clarify before querying

Ask anything still unresolved. Do not guess.

Scope. Default is selected branches: roles absent from the artifact stay. "Full hierarchy" still does not delete those roles unless the admin asked for each deletion.
User reassignment. Default is no. Do not emit
```
AssignUser
```
or
```
MoveUser
```
without an explicit yes.
Ambiguous identities. Resolve every role and user in one batch. See step 2.
Conflicts. Two parents for one role, or a role parented to itself: stop until the admin picks.

If the artifact matches fewer than 20% of its roles to the current tree, stop and ask whether it is a greenfield replacement, the wrong file, or a mapping problem. Do not build a manifest until the admin confirms a greenfield replacement. Between 20% and 50%, show the fraction in the preview and continue.

1. Read the current hierarchy

text

SELECT Id, DeveloperName, Name, ParentRoleId
FROM   UserRole
LIMIT  10000

Match artifact roles by

DeveloperName

, then case-insensitive

Name

2. Parse the artifact and resolve identities

Normalize to

{roleName, parentRoleName, users?}

and show that list to the admin before the diff. A PDF that is not text-selectable cannot be parsed. Ask for a plain-text

Role: Parent

list.

Roles: exact

DeveloperName

, then case-insensitive

Name

. No fuzzy match. When more than one role matches, list each candidate's

DeveloperName

and

Id

and wait. Do not pick one. Unresolved names go back to step 0.

Users, only after reassignment was confirmed:

18-character id starting with
```
005
```
→
```
User.Id
```
Email →
```
User.Email
```
Username →
```
User.Username
```
Display name →
```
User.Name
```
, and only when exactly one active user matches

IsActive = false

is a non-match. A user listed under two roles is a conflict. Ask which role that user should land under, or whether to drop the reassignment. Do not submit until the admin answers.

Stop on a cycle in the target graph. Report the path, for example

A → B → C → A

, and ask for a corrected artifact. Do not submit.

3. Build the manifest

Each mutation has

operationId

operationType

dependsOnOperationIds

, and one nested payload.

dependsOnOperationIds

is the order that matters.

operationType	Nested object	Use when
`CreateRole`	`createRole`	Role is in the artifact and not in the org. Set `roleReference` , `developerName` , `name` , and `parentRoleId` or `parentRoleReference` . Default the three account-owner access fields to the org defaults when the artifact omits them.
`ReparentRole`	`reparentRole`	Role exists and the parent differs. Set `targetRoleId` or `targetRoleReference` , `expectedParentRoleId` , and `desiredParentRoleId` or `desiredParentRoleReference` .
`RenameRole`	`renameRole`	Same role, different label or developer name. Set the expected and desired name fields.
`DeleteRole`	`deleteRole`	Admin asked to remove an empty role. Set `targetRoleId` , `expectedParentRoleId` , `expectedAssignedUserIds` , and `expectedDirectChildRoleIds` .
`AssignUser` or `MoveUser`	`userRoleAssignment`	Reassignment was confirmed. Set `userId` , `expectedCurrentRoleId` , and `desiredRoleId` or `desiredRoleReference` .

DeleteRole

applies only when the role has no direct children and no assigned users at the moment it runs. Reparent those children and move those users in earlier mutations, and put those

operationId

s in

dependsOnOperationIds

. The delete's expected user and child lists are then empty. If the admin declined reassignment, do not delete a role that still has users.

A mutation that names a role neither in the org nor created in this manifest is

missing-parent

. Name the roles that point at it. Ask whether to add a

CreateRole

for it in this manifest, skip those rows, or abort. Do not submit with that parent missing.

A cycle in

dependsOnOperationIds

blocks the submit. Give every new role a

roleReference

string and point parents and assignments at that string.

4. Validate, then preview

Block the submit when any of these remain: a cycle, a missing parent, a duplicate

developerName

, a dependency cycle, an

AssignUser

MoveUser

without the step 0 yes, a

DeleteRole

whose expected user or child lists are not empty, or overlap under 20% without a confirmed greenfield replacement.

On a duplicate

developerName

, show both rows and wait until the admin picks one or renames one.

Warn in the preview, and continue only after an explicit yes:

A changed role is referenced by
```
Territory2.UserRoleId
```
or a forecast hierarchy override.
A changed role has
```
PortalType != 'None'
```
.

A changed role has more than 500 users (

SELECT COUNT() FROM User WHERE UserRoleId = :id

text

Restructure preview
-------------------
  ReparentRole : 42
  CreateRole   :  3
  RenameRole   :  1
  DeleteRole   :  2
  MoveUser     :  2

  Territory / forecast references : 1
  Portal roles                    : 0
  Roles with more than 500 users  : 2

Approve this restructure? [yes / no]

yes

submits. Anything else does not. Roles left in the org and absent from the artifact stay in place.

5. Submit

text

POST /services/data/v{version}/sharing/role-hierarchy-restructure
{
  "operation": "Save",
  "mutations": [
    {
      "operationId": "reparent-sales-vp",
      "operationType": "ReparentRole",
      "dependsOnOperationIds": [],
      "reparentRole": {
        "targetRoleId": "00E000000000001",
        "expectedParentRoleId": "00E000000000002",
        "desiredParentRoleReference": "cro"
      }
    },
    {
      "operationId": "delete-legacy-region",
      "operationType": "DeleteRole",
      "dependsOnOperationIds": ["reparent-legacy-children"],
      "deleteRole": {
        "targetRoleId": "00E000000000003",
        "expectedParentRoleId": "00E000000000002",
        "expectedAssignedUserIds": [],
        "expectedDirectChildRoleIds": []
      }
    }
  ]
}

CreateRole

RenameRole

AssignUser

, and

MoveUser

use the same envelope with their nested object from step 3.

Send the approved manifest once. Do not edit

UserRole

records one by one.

6. Read the response

```
Applied
```
— structural and sharing changes committed.
```
AppliedSharingPending
```
— hierarchy is live; sharing catches up on its own. Do not poll.
```
AsyncExecutionRequired
```
— the server queued the manifest. Do not poll.
```
RoleOperationInProgress
```
— another restructure is running. Stop. Do not queue the manifest. Ask the admin to retry once the other operation finishes.
```
NotApplied
```
— nothing committed. Show
```
reasonCodes
```
and stop.
```
404
```
on submit — API not enabled for this client tier. Halt, tell the admin, do not retry, do not fall back to per-record
```
/sobjects/UserRole
```
edits.

For each

operationResults[]

entry,

outcome

Applied

NotApplied

, or

DependencyNotApplied

. Show

reasonCode

for any entry that is not

Applied

. Do not retry and do not roll back.

Out of scope

A single role create, rename, or reparent with no other changes, and any request that only asks which roles exist or how they are nested (
```
managing-roles
```
).
Territory, account, and forecast hierarchies.
Authoring sharing rules.
Image-only PDFs. Ask for text.
Rollback. Report what the response says was committed.

Operations Reference

Operations this skill uses — routing and dependency reference.

Operation	Purpose	Status	Call	Depends on
`read-role-hierarchy`	read	—	`GET /services/data/v68.0/query`	—
`count-users-per-role`	read	—	`GET /services/data/v68.0/query`	`read-role-hierarchy`
`submit-role-hierarchy-restructure`	write	—	`POST /services/data/v68.0/sharing/role-hierarchy-restructure`	`read-role-hierarchy`
`verify-role-hierarchy-restructure`	verify	—	`GET /services/data/v68.0/query`	`submit-role-hierarchy-restructure`

platform-role-hierarchy-apply

NPX Install

Tags

SKILL.md Content

Role Hierarchy Restructure

Inputs

Flow

0. Clarify before querying

1. Read the current hierarchy

2. Parse the artifact and resolve identities

3. Build the manifest

4. Validate, then preview

5. Submit

6. Read the response

Out of scope

Operations Reference