Prepare, review and publish an organization structure¶

A structure draft lets an authorized editor prepare a proposal before it becomes the current organization structure. Publication is a separate decision with its own permission. Agree who owns the proposal, who checks reporting and cover, and who may publish it.

These steps follow the intended WorkOS Final Screens. The inspected frontend still demonstrates sample structures and simulated save messages; connected saving and deployment have not been verified. The current backend also has the specific limits explained below. Treat this as a guide to the intended journey and verified rules, not confirmation that every action is available in your environment.

For navigation, assignment history and the meaning of coverage and risk summaries, first read Explore your organization and review coverage. Detailed editing of units, positions, assignments and shared queues remains under documentation reconciliation.

Before you begin¶

Confirm the workspace and structure you intend to change. You need permission to edit the Organogram to create, change, validate or delete a draft. Publishing requires separate publication permission. Read access alone is insufficient; an organizational title does not automatically grant these permissions.

Decide whether to copy an existing published structure or start without a source. A copy creates a separate draft; it does not rename or replace the published source. Starting empty creates an unpublished proposal that still needs its units, positions and cover arranged before publication. The root is the unit designated as the structure's starting point. When no root has been designated, the backend can infer it only when the draft has exactly one top-level unit. No top-level unit or several possible roots blocks publication. This limitation needs review before relying on an empty draft for a launch or reorganization; connected saving and delivery still require verification.

For business reviewers, prepare a clear purpose, scope and intended transition. Review who will hold accountable positions, how absence cover works, and which operational destinations depend on the structure. A ready result is only the result of the implemented checks; it is not organizational approval or a guarantee that every workflow has been exercised.

Create a draft¶

1. Open Operations → Organogram → Structure views in the intended workspace.
2. Choose Create draft.
3. Choose the published Source structure to copy, or leave it empty after considering the limitation above.
4. Enter a Draft name of up to 200 characters and a Draft code of up to 50 characters. Use a distinct code: saved structure codes must be unique within the organization, including historical structures.
5. Add an optional Description, up to 1,000 characters, to explain the proposal.
6. Review the source and identity, then choose Create draft. Confirm that the returned draft appears and opens with the expected name, code and contents before continuing.

Names are trimmed and codes are stored in uppercase. New drafts start active and unpublished. The source is selected only during creation; changing draft settings later does not switch its source.

Check the description after copying. The current copy operation keeps the published source's description and ignores the new description entered on the creation form. Open Draft settings and save the intended description there. A draft created without a source stores the entered description.

Review what was copied. The implementation creates new structure, unit and position identities while retaining references to the same people and reusable job titles. It copies saved assignment and relationship date ranges, including historical entries; this is not a promise to copy only today's cover. Shared queues need particular attention: a queue with no unit and no currently effective position membership can be omitted. Do not assume a copy includes every shared work destination merely because its hierarchy looks complete.

If a request appears to be taking too long, check whether the draft was saved before starting another creation. The connected application must safely retry the original operation. Repeated clicks with newly created requests are not a substitute for checking the result.

Change draft settings¶

1. Open the intended draft and choose Draft settings.
2. Update Draft name, Draft code and Description as needed, using the same length limits as creation.
3. Review Draft is active. It records the draft's active state; it does not publish it.
4. Choose Save changes, then reopen or refresh the draft to confirm the saved values.

These settings apply only to an unpublished draft. Published structures cannot be renamed through this draft-settings action. The design currently says inactive drafts are unavailable for editing, but the backend does not enforce that restriction on draft settings. Do not treat this switch as an edit lock or a substitute for permission control. Publication can make an inactive draft active.

Cancel leaves the intended form without submitting the change. In the current frontend demonstration, neither a toast nor navigation back to the hierarchy establishes that information was persisted.

Review and validate¶

1. Open the selected draft's hierarchy and review the actual units, positions, people and date ranges.
2. Open Risks and inspect each affected item. Several rows can describe the same underlying gap.
3. Use Simulation to review publication issues alongside the selected operational risks. Simulation does not publish or execute a workflow.
4. Choose Validate draft. Check that the result refers to the draft you opened and that the draft loaded successfully.
5. If critical publication issues remain, correct the affected draft information through the authorized editing process and validate again.
6. If the result is ready, review any remaining warnings and obtain your organization's required approval before publishing.

Ready does not necessarily mean zero issues. Warnings can remain; any critical risk included by the publication checks blocks publication. A missing structure now fails validation, and an already-published structure is not a publishable draft. If a root has already been designated, it must belong to the selected structure. Otherwise exactly one top-level unit is needed so the root can be inferred. Validation does not itself save that inferred root: the publication operation attaches it before changing the current structure. See risk and validation limits for the limits of these checks.

Publish the reviewed draft¶

1. Confirm the draft name, code, intended transition and latest review result.
2. Choose Publish structure from the validation result. This action requires publication permission.
3. Read the confirmation naming the draft. Choose Cancel if the selected structure or timing is wrong.
4. Choose Publish to submit the operation.
5. Read the returned result. If blocking issues are returned, publication has not completed; return to the affected items, correct them and validate again.
6. After a successful result, reopen Structure views and confirm that this structure is current. Verify the operational handoffs relevant to your organization before declaring the change fully rolled out.

A prior ready result is not a reservation or a promise that a later attempt will succeed. Publication validates again, and saved structure information can change between reads. The current flow provides no warning-acknowledgement override for a critical issue. Review remaining warnings under your organization's approval process.

Successful publication makes the draft published and active, records the publication time, and makes the previous current published structure inactive. That prior structure is retained. The same published structure cannot be published again, and this flow does not provide an undo-publication action. Agree a recovery plan with the structure owner before an important transition.

Related staff-placement and analytics information updates through separate processing. Successful publication does not mean every screen has already refreshed or every ongoing work item has changed destination. Check the operational handoffs relevant to your organization. The catalogue itself is not a complete archive browser for every superseded structure.

Delete an unwanted draft¶

1. Open the draft and go to Draft settings.
2. Check that you are discarding the correct unpublished proposal. Keep any business decision record through your organization's approved process.
3. Choose Delete draft and read the confirmation naming it.
4. Choose Cancel to retain it, or Delete draft to confirm permanent removal.
5. Refresh the catalogue and confirm the result.

The deletion operation rejects published structures. Successful deletion removes the draft and its loaded structure records; it is not an archive or a reversible hide action. There is no restore-draft action in this journey. Other drafts and the published source are not selected for deletion.

Some saved shared-queue arrangements can currently prevent deletion. If removal fails, retain the draft and ask support to investigate. Do not repeatedly recreate or publish it as a deletion workaround.

Resolve a failed or uncertain action¶

Keep sensitive personnel details out of general support messages. Use your organization's approved channel when evidence needs restricted access. These guides remain subject to the initial audience review and connected-environment verification.

For the individual changes inside a draft, follow Maintain titles, units, positions and assignments. Review its relationship-clearing, assignment-window and shared-membership limits before editing.

Read How your organization structure directs work before interpreting a newly published structure as a change to every task recipient. Profile placement, direct-position routing, manager routing and shared queues use different rules.