Review, approve and recover a change¶

This guide follows the current HiveAI Final Screens. The frontend remains in progress, so some controls may not yet be available in your environment. The example screens use a workflow-task reassignment; the same review principles apply only where another supported action provides its own verified details.

Before you begin¶

Use the correct workspace and a supported HiveAI conversation. You need permission for the actual work you are asking to change, as well as the applicable HiveAI access. If the work is restricted or unavailable, ask your workspace administrator or the person responsible for that work to check your access.

Know the intended result before approving. For reassignment, identify the task and the colleague who should receive it. If the assistant has selected the wrong task or person, reject that proposal and clarify your request.

Ask for a supported change¶

1. In the conversation, describe the work and the change you want.
2. Answer any request to identify the correct item or provide missing information.
3. Wait for a specific review of the proposed change.
4. Compare that review with your instruction before making a decision.

An explanation, recommendation or prepared draft is not evidence that a business action has been executed. If no actionable review appears, follow the clarification or unavailable message; do not assume that the original instruction was sufficient approval.

For ordinary conversation entry, target selection and continuation, use the conversation guide.

Review the exact change¶

The inspected assignment review identifies the task, the current assignee, the proposed assignee, the time until which the review is valid, and the conditions for a possible later restoration.

Check these points together:

Do not approve a proposal whose material details you cannot inspect. The mobile review still needs design reconciliation for some expiry and restoration information. If those details are missing, use a view that provides the complete review or wait for the experience to be corrected.

Approve or reject the proposal¶

1. Read the exact change and its conditions.
2. Select Approve change if it matches your intention, or Reject change if it does not.
3. Wait for the saved decision or progress state.
4. After approval, follow the execution result before considering the work complete.

Approval starts the governed execution process. It does not immediately confirm that the source has applied the change. Rejection declines this proposal; a different desired change requires its own review.

If the screen changes while you are deciding, refresh and review the current information. Repeating a decision against an old screen can be refused.

Give a spoken decision¶

Where the speech review is available:

1. Read the proposed change before entering the speech decision flow.
2. Review the recording allowance and choose Start speaking.
3. State your decision.
4. Read the resulting transcript and edit it if it does not express your intention.
5. Choose Submit decision only when the transcript is correct. Use Discard recording to abandon that recording.
6. Follow the saved decision and action result.

The ready screen also offers Back to review. A recorded word or a displayed transcript alone is not a completed business change. Submission sends the decision into the governed process.

Recording costs and the action's conversation costs are shown separately. The example values in the design are illustrative, not a price guarantee for your next request. See the speech guide for recording, transcript and playback details.

If the review is unavailable or expired¶

1. Read whether the review is unavailable or has expired.
2. Choose Refresh review to retrieve the current saved information.
3. Check the target, values and validity again if a usable review appears.
4. If a fresh proposal is required, review it as a new decision.

An expired approval does not regain validity merely because the page was refreshed. A changed source item may require a new proposal. Preserve an already approved action whose outcome is unknown while that outcome is investigated.

Follow an approved change¶

The approved state can mean the decision is saved and execution is waiting to begin. The processing state means work has begun but its final source outcome may still be unconfirmed.

Use Refresh status to read saved progress. The screen may show preparation completed while the assignment change remains in progress. Those are separate steps.

Do not create another request just because progress has not changed immediately. Follow the original change until it reports a result or a supported recovery action.

Stop work that has not finished¶

Before dispatch, the approved waiting screen offers Stop change. While processing, the design offers Stop remaining work with a warning that work already accepted by WorkOS cannot be recalled by that control.

1. Read which work has already completed or been accepted.
2. Use the available stop control.
3. Read the resulting saved status.
4. If the result remains unconfirmed, continue checking the original operation.

A stop request does not undo completed work. The current backend also distinguishes stopping an undispatched proposal from cancelling its conversation. Do not assume that stopping the conversation stopped an already approved change.

Only a confirmed result that says the action stopped before reaching the source establishes that particular boundary.

Recover an unconfirmed outcome¶

The unconfirmed-outcome screen offers Recover original change and Refresh status.

1. Keep the original change open.
2. Select Refresh status if you only want to read its saved state.
3. Select Recover original change when you want the system to check and recover that same approved operation.
4. Read the recovery explanation: after checking the source, recovery may allow the original approved change to continue.
5. Choose Confirm recovery to proceed, or Keep waiting to leave that recovery decision unsubmitted.
6. Read the recovery result before taking another action.

Recovery preserves the original change. A different assignment, target or instruction needs a new proposal and review after the original outcome has been resolved.

Understand the recovery result¶

A missing result, an unavailable source and a confirmed failure are different conditions. If you cannot determine which applies, keep the original request for support to investigate.

Verify a completed change¶

1. Read the specific confirmed outcome.
2. Use Open task, or the source link provided for that type of work.
3. Confirm the expected result in the owning application.
4. Return to the conversation if you need its final explanation or cost update.

The source result can be confirmed while the conversation still says it is updating. Likewise, completing one action does not establish that later approvals, notifications, imports or other background processes have finished.

If the source link is unavailable, retain the original request details and ask for help locating the affected work. Do not repeat the action solely to obtain a working link.

Review a supported restoration¶

The completed assignment example offers Review restoration. It describes a separate approval and requires the task to remain suitable for restoration.

1. First confirm the original change's outcome.
2. Choose Review restoration if it is offered.
3. Inspect the newly proposed corrective change, including the actual assignment it would restore.
4. Approve only if that proposal matches your intention and remains current.
5. Follow the corrective change to its own confirmed result.

The backend's assignment-restoration path still needs verification that it preserves the true previous assignment. Do not rely on the presence of the control as proof that the proposed correction is right. Check the actual values carefully.

A restoration proposal does not itself restore anything. Some actions have no supported inverse. For example, archiving a still-editable memo draft is a narrower operation than recalling a memo already submitted into a business process.

Interpret costs during approval and recovery¶

Review preparation, speech recording and later conversation work can have different allowances and recorded costs. Read the label for the part being shown.

A displayed maximum is a limit or estimate for its stated context. “Used” and “released” are different amounts. An unavailable amount is unknown, not zero.

A confirmed task change does not establish that its conversation cost has finished settling. Avoid repeating generation to make a missing cost appear. Use the credits and budgets guide for reservations, final charges and unresolved provider work.

For administrators, managers and support¶

Confirm that the workspace policy, capability, source permission and affected user's access support the requested change. A manager title alone does not establish authority for every action.

When a request needs investigation, record the workspace, recognizable work item, approximate time, intended result, last visible state, and any reference the product shows. Explain whether you approved, stopped or requested recovery. Share these details through your approved support channel.

Do not ask a user to repeat an unresolved change as the first recovery step. Locate the original operation and distinguish the source's result from the conversation's presentation.

For executive reporting, count confirmed business outcomes separately from proposals and approvals. Treat partial work, uncertain outcomes and corrective actions as distinct follow-up categories.