Set or change your authorization PIN¶
Draft intended journey. These steps follow WorkOS 06 Final Screens. The current frontend presents sample request, verification, entry and success states; its controls do not call the PIN service. A displayed success in that frontend does not change your PIN. Connected delivery and reader acceptance are pending.
Use this flow for the authorization PIN belonging to your staff record in the selected workspace. For the password used to sign in, use password recovery.
Before you begin¶
You need to be signed in, able to open WorkOS in the intended workspace, and able to receive mail at the email address on that workspace's staff record. A personal Zerohive account or a manager's permission does not automatically provide those prerequisites.
Open My account, then Authorization PIN. The intended screen has three stages: Request Code, Verify Code and Set New PIN. The exact placement of My account depends on the delivered shell. Do not use a copied link from another workspace to bypass the normal entry.
Keep the PIN and temporary confirmation code private. Support can investigate with a workspace, time, visible message and support reference; it does not need your PIN, code or hidden verification information. Enter credentials only into the appropriate connected product screen.
Request the confirmation code¶
- In Request Code, check the read-only Work Email.
- If it is the intended staff email, select Send Code.
- Open the PIN-update message in that mailbox.
- Continue to Verify Code in the connected flow.
If the address is wrong or inaccessible, stop and ask the organization administrator or support to investigate the staff email. This step does not offer an editable destination. The backend selects the current staff member's email; changing a URL or a sample label is not a way to redirect delivery.
Issuance creates a six-digit code for PIN updates. It expires 30 minutes after issuance; time spent waiting for email uses part of that period. A newly issued code replaces the previous pending code for this purpose. Use the newest PIN-update message, not an account-activation, sign-in or password-reset code.
Cancel leaves the intended flow before completion. The inspected backend has no separate cancel-PIN-update action, so leaving a screen should not be described as immediate revocation of every previously issued confirmation.
Verify the code¶
- Enter the message's code in Confirmation Code.
- Select Verify Code.
- Continue to Set New PIN only after the connected service accepts it.
The intended screen also provides Cancel. A rejected or expired code means you should return to Request Code and begin a fresh attempt. Requesting another code and verifying it are separate actions; opening a step does not send mail.
A successfully committed confirmation consumes the pending code. If the browser loses the confirmation result, a second attempt with that same code may fail. Restart the flow instead of asking someone to expose or alter hidden values.
The 30-minute period applies to the pending email code. It is not a promise that every later step has a separate 30-minute window. The current confirmation and completion controls still require engineering qualification.
Save the new PIN¶
- In Set New PIN, enter the value in New Authorization PIN.
- Review it carefully, then select Save PIN once.
- Wait for the connected application to report the result.
- Use the new PIN the next time a supported action in that workspace asks for it.
The inspected final design has one new-PIN field and a Back action. It does not ask for the old PIN or a second confirmation field. Do not assume that losing the old PIN prevents this email-confirmed journey.
The backend does not currently establish a six-digit new-PIN rule, a repeated-digit or sequence restriction, a 90-day rotation period or an administrator-unlock process. Some current frontend sample panels contain those statements; they are not reliable product requirements. Follow requirements actually enforced by the connected product and report a mismatch to support. The six-digit email code and the new PIN are different values.
Choose a private value that is difficult for others to guess. Do not use a shared team PIN or disclose it in a chat, email, document, screenshot or assistant conversation.
Understand the result and notices¶
Saving a PIN is separate from the work that prompted you to set it. Return to the original signature, mailbox or other supported task afterwards and review that task's requirements. A PIN update does not automatically complete it.
The backend requests an Authorization PIN changed email and an inbox notice. Delivery may lag behind the saved change. Receiving the initial code email does not mean the PIN changed, and missing a change notice does not prove that it failed.
The current frontend's Updated state is demonstration content reached through navigation. It is not a service receipt. The final designs inspected for this guide establish the three entry steps; a fully connected completion and interruption journey remains to be verified.
If a protected assistant journey brought you to PIN setup, finish it in the secure account surface and return through the supported flow. Do not paste the PIN or code into the assistant. Completing setup alone does not prove that a separate assistant action completed.
Recover from an interruption¶
| Situation | What to do |
|---|---|
| No code email | Check Work Email and filtered mail. Request one fresh code; contact support if it still does not arrive |
| Code is rejected or expired | Check its purpose and use the newest PIN-update message. Return to Request Code if necessary |
| Verification appeared to succeed, then the page was lost | Begin a fresh request and confirmation rather than reusing hidden state |
| Save PIN failed or its result is unclear | Avoid repeated submissions. Record the failed stage and message, then ask support to establish whether the change was saved |
| Another task still rejects the new PIN | Confirm the workspace and the action's access requirements. Report the mismatch without sharing the PIN |
| The page says Updated immediately after navigating | In the current WIP frontend this is a sample state; it does not establish a saved change |
| You receive an unrecognized PIN-change notice | Contact your established support or security channel promptly |
An interrupted save is not a reason to test an unrelated high-impact action. Support should establish the outcome without asking you to sign, approve or send something merely to check a credential.
Workspace access and interrupted requests¶
If you cannot enter the workspace or receive a workspace-access message, do not assume your PIN or email code is wrong. Account access, product assignment, workspace subscription coverage and an administrative pause are separate checks. Ask the organization administrator to review the visible cause through product access. A payment cannot remove every administrative pause, and this PIN journey is not a way to restore workspace access.
If access changes or the connection closes after you submitted a step, keep the original attempt and follow the interruption guidance above. An interrupted response does not establish whether that step saved. Do not reset unrelated credentials or share a code with support to try to bypass the restriction.
Access problems and safe support¶
If WorkOS is unavailable, resolve workspace or product access first. The PIN cannot grant those permissions. If the current staff record cannot be resolved, support needs to investigate the identity-to-staff relationship in that workspace; this is different from an incorrect code.
Give support the workspace name, approximate time, failed stage, visible error and any available support reference. Redact credentials and other people's information from screenshots. Never send the PIN, temporary code, browser cookies or hidden verification information.
Changing a PIN does not promise to end existing sign-in sessions, revoke external mailbox authorization or undo work already completed with it. If you suspect misuse, follow your organization's incident process in addition to changing credentials.
Guidance for each reader¶
Users: keep the workspace and mailbox consistent throughout the journey. Use the connected service result, not a sample success panel, to establish completion.
Managers and executives: keep responsibility for work approval separate from credential maintenance. Do not share PINs or interpret the change as delegation, mandatory periodic rotation or an assurance that every sensitive action uses the PIN.
Organization administrators: help resolve WorkOS membership, staff identity and the recorded email through the appropriate authorized process. This self-service journey does not establish an administrator reset or unlock operation.
Platform staff and support: separate code issuance, confirmation, PIN persistence, notices and the dependent task. Investigate uncertain outcomes without collecting credentials.
Engineering, design and operations teams: qualify the stored confirmation lifecycle, authority, validation, replay, messaging and connected completion experience. The private reference records exact sources and unresolved constraints. All nine audience reviews remain pending.