A service ticket is closed after a vendor resolves a delivery exception. Later, an operator notices a typo in the record and an automation asks to call a provider action. Those are two different decisions: what may change on a closed ticket, and whether a plugin action is available and permitted. Latch keeps those controls separate so a setting in one area does not quietly grant authority in another.
Decide what can change after closure
Ticket immutability is enabled by default. When it is on, Closed and Cancelled service tickets reject changes to fields other than status. This lets a team keep a closed record stable while still allowing a status transition when the configured workflow calls for one. It is an application edit rule, not a guarantee of legal retention or tamper-proof records.
Before changing the setting, decide how the team handles a correction discovered after closure. If the record must remain stable, preserve the original ticket and document the follow-up through the supported workflow. If a correction requires a field edit, the administrator needs to understand that changing the control changes the behavior for those closed records. The control applies to service tickets; it does not replace retention policy or an external audit requirement.
Treat plugin access as several gates
Plugin availability starts with the effective runtime feature entitlement. New free workspaces start with plugins unavailable. That entitlement is separate from a user’s role permission, from a provider’s approval status, and from whether the relevant plugin module is available in the running application. A visible setting or a broader user role does not manufacture missing entitlement.
Consider a case-routing action that can open a work order with an external provider. The workspace first needs the plugin capability enabled. The acting user then needs permission for the action, and the provider must be configured and approved where approval is required. Each check answers a different question: may this workspace use the capability, may this person invoke it, and may this connection be used for this action?
Review those decisions together before enabling an action. A workspace can have plugin access without giving every user the same tools. An administrator can narrow role permissions without changing the entitlement. Provider approval can be withdrawn without changing the ticket edit rule. MCP agent profiles have their own delegated permission and credential lifecycle; they do not collapse these gates into one switch.
Review the action path before enabling it
Use a real operating example to test each control. Confirm the closed-ticket behavior with a Closed or Cancelled service ticket, then check the action using an authorized user and an approved provider. If a call crosses a network boundary, review the provider connection policy separately. If an administrator cannot distinguish entitlement, permission, and approval in the test result, the access model is not ready to expand.
For teams that need a controlled handoff after an employee loses an authenticator, review the TOTP recovery flow and its post-reset sign-in gate. That is another narrow control with its own conditions. Keep each rule tied to the decision it governs, document its owner, and verify the denied path before relying on it in daily work.
The plugin workflow guide explains when configuration or an external action belongs in the operating process.