Review and recover AI-assisted case changes¶
HiveAI can prepare structured requests to change casework. These include creating a case, adding people or notes, recording decisions, managing tasks, linking related work and handling formal HR queries. Asking for information and approving a change are separate activities. A suggested change does not establish that anything has been saved.
Availability: this draft explains implemented case-action capabilities and their limits. The inspected frontend and Final Screens do not yet establish a complete, connected case-assistant journey. The inspected HiveAI designs demonstrate general proposal, approval and recovery patterns using workflow-task examples. Exact case controls, role/device variants and environment delivery remain unverified. Use the ordinary case guides for the intended WorkOS journeys. The guidance below explains what to check when an assisted case action is offered; it does not promise that every action is available in your application.
Before requesting a change¶
Confirm the workspace and the case reference. Check the current case, its owner, confidentiality, stage and status. State the change you want and identify the people, dates and related work precisely. For example, adding someone as a participant differs from recording them as the staff member concerned by an HR matter. A due date also differs from a target resolution date.
You need both the appropriate HiveAI access and permission to change the case. General case access does not grant protected HR access. Employees responding to their own HR queries use a separate permission and must be the named subject. Starting a workflow or linking a record, communication or external exchange adds that source's access requirements. Current licensing, governance and usage controls still apply; check your workspace's current terms for prices and allowances.
The assistant uses the existing case rules. It cannot make a protected case type editable, bypass a required dossier or response, close a case without its closing requirements, or turn an ordinary participant into an authorized HR manager. Check the relevant guide before approving a consequential change.
What the case actions can do¶
The implemented action set contains 27 operations. Related operations are grouped below so readers can find the appropriate ordinary guide and understand their different effects.
| Action | What to review and what it means |
|---|---|
| Create a case | Review type, title, description, staff subject/role, organizational responsibility, dates, stage and confidentiality. The signed-in actor becomes owner. See Create a case. |
| Add a participant | Check the selected person and participation role. This is not a change of case ownership. |
| Add a staff party | Check the staff member and their role in the matter; this is distinct from participation and requires HR authority. |
| Add a note | Read the full note and confirm the destination case. This assistant action adds a note; it does not edit or redact an existing note. |
| Record a decision | Review decision type, outcome, summary and any next stage. A stage decision does not by itself close the case. See Read and update a case. |
| Create or update a task | Check title, description, assignee and due date. For an update, also review status, result summary and any workflow link. An updated task is not automatically completed. |
| Link an existing workflow | Check that the workflow is the intended one and verify its current information in WorkOS. This does not mean the case started it. |
| Start a workflow from the case | Review the permitted workflow family, selected process, title and description. Starting the workflow and saving its case link are separate steps that can have different outcomes. |
| Link a record, correspondence item or external exchange | Confirm the exact source item and the relationship. The source supplies its current identifying information. A link neither transfers ownership nor grants new access. |
| Close a case | Review outcome and closing summary, and resolve closing blockers. Closing does not complete outstanding tasks or workflows. See Tasks, workflows, linked work and closure. |
| Create or update a case type | Review the full set of defaults, closure outcomes, roles, allowed workflow families, board/stage rules, dossier policy and record/correspondence requirements. An update can replace configured lists and rules; it is not safe to assume omitted settings stay unchanged. |
| Activate or deactivate a case type | Confirm the type and its protected-system restrictions. These actions affect type availability; they do not close existing cases. See Configure case types. |
| Save an HR notice draft | Check subject, complete notice text and response deadline. Saving is distinct from issuing the notice. |
| Issue an HR notice | Check the case, saved notice, future deadline and required dossier. Issuance starts a separate correspondence/delivery process. |
| Record an offline HR response | Check response text, received time, channel and any earlier response being supplemented. This is an HR management action. |
| Extend an HR deadline | Review the new deadline and reason, including the timezone. |
| Review or withdraw an HR query | Review the outcome or withdrawal reason and the resulting lifecycle effect. Some reviews close the query; investigation or disciplinary outcomes create related protected casework. See Manage HR cases and formal queries. |
| Respond to your own HR query | Review the full response and the correct query. The assistant supports a text response only; it does not attach files or identify an earlier response for a supplement. Use the appropriate employee response journey for supplementary replies. |
| Record an ordinary response, complete an escalation, or record a quality review | Review the evidence identity, outcome, proof and responsible contributor, plus the action-specific dates, resolution or findings. These differ from formal HR responses and ordinary case decisions. See Operational evidence. |
Review the exact proposal¶
Before approving an offered proposal, compare its destination and complete proposed values with your intention. Check names as well as identifiers, dates and timezones, recipients or staff subjects, and the effect on related work. For a case-type change, examine the complete resulting configuration. For an HR action, review the actual notice or response text in an authorized context.
The intended general HiveAI design separates reviewing a proposal from approving it. Approval applies to that proposal, not to any later interpretation of the conversation. If the proposal is wrong, reject it or request a corrected proposal through the available journey. Do not approve a partly correct request expecting to repair the rest afterward.
A prepared case-action preview is valid for five minutes. Approval and access can expire separately. The preview checks the selected case or type for changes; it does not reserve the case, lock related systems or prove every business rule will pass later. If relevant information changes, obtain and review a fresh proposal. Do not repeatedly approve an outdated one.
For record, correspondence and external-work links, identifying information is obtained from the related item when the change is made. Information may have changed since an earlier answer. For an existing-workflow link, verify the selected workflow and its current state in WorkOS.
Confirm the business result¶
After a change, read the action-specific outcome and inspect the current case through its normal authorized view. A message saying processing finished is not sufficient proof that the requested change was accepted.
This distinction particularly affects ordinary response, escalation and quality-review actions: a request can finish processing and return a rejected business result. The current general success summary does not reliably distinguish that result. Until the connected journey is corrected and verified, confirm the actual saved evidence with an authorized case manager or support team rather than relying on a generic confirmation.
Some results start further work. Issuing an HR notice does not prove delivery, filing a related record or receiving a response. Starting a workflow does not prove completion of its tasks. A saved relationship reflects the source information obtained for that link; it is not a promise of continuous synchronization.
Recover from an uncertain attempt¶
Keep the original proposal or action reference. An uncertain result calls for checking that attempt and the source work. Creating a fresh request immediately can duplicate work that already happened.
| Situation | Recommended next step |
|---|---|
| The preview expired or the case changed before execution | Read the current case and prepare a fresh proposal. Review all values again before approval. |
| Access or a business rule prevents the action | Resolve the stated permission, case-state, contributor, dossier or other requirement through the ordinary process. A new wording of the request does not grant access. |
| The action was submitted but its outcome is unknown | Use the available status/recovery journey for the original attempt and check the source. If it remains uncertain, give support the original reference and time. |
| A workflow exists but is not linked to the case | Ask an authorized operator to reconcile the existing workflow and case link. Do not start a second workflow merely because the link is absent. |
| A generic confirmation conflicts with a rejection or missing evidence | Check the action-specific business result and source history with the responsible team. Report the conflicting confirmation. |
| The case changed but the assistant conversation has not caught up | Refresh the source and conversation separately. A delayed conversation does not undo the change. |
| No saved result can be found | Treat the outcome as unresolved until the source is checked. Absence of a result record alone does not prove nothing happened. |
The inspected general designs distinguish refreshing status from recovering an original change; recovery may continue work after checking its state. The case-specific implementation and controls still require verification. Do not assume that a button from a workflow-task example is present or has identical behavior for cases.
There is no general case-action undo operation in this implemented set. Some ordinary actions may have their own correction procedure, but a completed case change, issued notice or started workflow must be assessed under that procedure. A restoration option shown for a different HiveAI action does not establish case reversal support.
For managers and support teams¶
Track the requested business outcome, the actual case result and any dependent workflow or communication separately. Preserve accountability for who requested and approved the change. An assistant confirmation is not evidence of complete delivery, policy compliance, improved productivity or financial savings.
When reporting a problem, include the workspace, case reference, original action reference, time, intended change and observed result through an approved channel. Avoid placing confidential notice text, personal information or credentials in unrestricted tickets. The responsible team should establish the original outcome before arranging a new attempt or a corrective action.
For information-only questions and incomplete answers, see Understand case information returned by HiveAI. Audience review and connected case-assistant acceptance remain open.