Governed policy changes, activity and retained data¶

SLA policies affect who is warned, when work becomes overdue and how responsibility changes. An assisted change therefore needs a precise proposal, an authorized decision and a confirmed result. A suggestion or an approval alone does not prove that the policy changed.

Availability: The backend contains a governed HiveAI path for creating, updating and deactivating SLA policies. Its source checks are described here, but the complete approval journey, connected screens and environment delivery have not been verified. A gap in supplying the acting person's profile to activity recording also remains unresolved. These are capability and review explanations, not instructions for a verified live assistant journey. The ordinary intended editor journey is in Manage SLA policies.

What a proposal can change¶

A creation proposal supplies a policy key, name, optional description, response and completion targets, warning lead and escalation rules. An update supplies the complete replacement settings and rule list for the selected policy. A deactivation proposal identifies the policy to make inactive.

The policy overview explains timing and lifecycle rules that still apply: business-calendar timing, separate response and completion targets, escalation after the completion deadline, saved timing on existing tasks and the consequences of deactivation. Using assistance does not remove those rules, choose a replacement policy for dependent definitions or cancel existing work.

For this governed path, a proposal can contain up to 50 escalation rules. Each rule's reason is limited to 512 characters. These are limits checked by the governed-action implementation; they do not establish that the ordinary editor exposes or validates every limit in the same way.

Creating a policy requires an unused key. Updating or deactivating requires the selected saved policy. Deactivation of an already inactive policy is unavailable through this path; editing an inactive policy does not reactivate it. A proposal to change a policy must remain attached to that policy rather than silently switching to a similarly named record.

Review the exact change¶

The system prepares a consistent version of the proposal and records which policy state it inspected. It checks the organization and the supplied authority to manage workflow definitions. A preview is given a five-minute expiry; other authorization may expire sooner. That period is not a reservation of the policy or a promise that the proposal will remain executable.

Before authorizing a change, the responsible administrator should review:

• The organization and selected policy, including its key and active status.
• The response, completion and warning settings in the organization's business calendar.
• Every replacement escalation rule, its timing, destination and reason.
• The effect on dependent definitions and future tasks, while recognizing that existing task timings remain saved separately.
• The acting person's authority and whether the proposal still represents the intended change.

These are review responsibilities, not screen labels or a claimed button sequence. The final assistant screens and their approval/recovery companions still need their own verification.

Why execution can be refused¶

Execution checks the approved target, exact proposal content, permission and authorization expiry. It also rereads the policy state, or checks that a new key is still free. A policy changed since preview can require a new proposal and review. Another administrator claiming the same key can prevent creation.

If a proposal expires, the policy changes, permission is no longer sufficient or the proposed settings are invalid, obtain a current proposal rather than treating the earlier approval as permanent authority. Preserve the intended change, but review it against current policy details before authorizing it again.

These checks do not yet establish complete protection against simultaneous changes between checking and saving. The running-system concurrency and authorization tests remain outstanding. Do not assume the ordinary editor has the governed path's preview-and-version checks.

Confirm the outcome and handle uncertainty¶

When a change succeeds, the system returns a result identifying the created, updated or deactivated policy. A recorded result can instead report that the change was refused. A successful preview, a submitted approval and a completed change are different milestones. Even a successful change does not prove that new tasks, alerts or email delivery have been exercised.

When a result is unclear, check the latest policy details and the recorded action outcome through authorized support. Keep the time, organization, policy identity and requested change available. Avoid repeated new submissions merely because a response was lost: they can represent separate requests. Support needs to distinguish a pending attempt, a recorded result and an attempt for which no result is available.

The current implementation has a specific unresolved dependency: activity recording needs the acting person's identity, email and display name, while the governed action itself supplies only the identity. Whether the running system supplies the remaining profile information must be verified. Until that path is reconciled, this documentation does not promise successful governed changes in an environment.

What activity records establish¶

Policy creation, updating and deactivation include activity recording. Each record identifies the action, person, policy and occurrence time. It provides accountability for an operation, but it does not include a complete before-and-after history of every setting.

Managers should compare current policy details with the approved proposal when checking a change. Do not use a policy activity entry alone to infer every old value, task deadline, notification recipient or delivered alert. Downstream activity delivery, visibility and retention require the activity service's own checks.

Support and administrators must handle names, email addresses, policy configuration and exported task information through authorized channels. Business leaders can use these records as part of change oversight, with explicit limits on what was recorded and verified.

Deactivation, export and deletion¶

Deactivation keeps the policy record and existing task timing. It is not a request to erase data.

Workflow tenant export and deletion declarations include SLA policies, their escalation rules, task instances and workflow instances. Task records carry the saved timing and progress described in deadline monitoring. The notification service separately declares its SLA email-dispatch records, which can contain recipient addresses and provider outcome information.

Being included in those declarations does not prove that an organization export or deletion has completed. Nor does it establish an automatic retention period, removal from backups or erasure at an external email provider. Activity history is a separate service responsibility. An authorized lifecycle operation needs its own completion evidence and must explain any retained or external data.

For end users, changing or deactivating a policy does not erase the history of their work. Administrators and support should explain that distinction when handling requests. The platform data-lifecycle overview explains the broader export and deletion boundary.