How should permissions change when a record moves from draft to finalized?

A record moving from draft to finalized should not trigger a wholesale rewrite of permissions. Keep durable authority such as who may edit, approve, or audit the record, then require two checks on every write: the actor must be allowed to perform the action, and the record must allow that state transition. This keeps authorization stable, makes finalization explicit, and avoids recreating memberships whenever business state changes. OWASP’s guidance usefully separates authorization by resource and operation and recommends deny-by-default and least privilege (OWASP Authorization Cheat Sheet).

What should change at finalization?

Change the allowed actions, not the underlying relationships. If Alice is an editor of Invoice 123, that relationship can stay true after finalization. What changes is that edit_content is permitted only while the invoice is in draft, while finalize is permitted only from draft, and create_amendment is permitted after finalized.

That design is more durable than removing Alice from editors and later adding her back. Relationship data answers who has standing authority on the record. The lifecycle state machine answers whether a requested action is valid now. Ory Keto is a good fit for the first part because it is a fine-grained permission system based on Zanzibar principles and supports relationship-based models and inheritance (Ory Keto documentation; Ory Keto GitHub repository). Your application service should keep the second part: business-state validation.

How do action checks and lifecycle checks work together?

Use authorization to answer “may this actor attempt this action on this record?” Then, in the same write path, have the domain service enforce the transition boundary before committing the change. Do not rely on a preflight permission check alone.

A safe ordering is:

1. Load current record state.
2. Check action authority, such as finalize on Invoice 123.
3. Validate the transition from the loaded state, such as draft -> finalized.
4. Write with a persistence condition that the state is still the loaded state.

That boundary matters. If two users act concurrently, the database write or equivalent persistence layer must reject a stale transition. You are not trying to make Ory Network implement your workflow rules; you are using Ory Network for actor-resource authorization, while the domain service remains the source of truth for lifecycle semantics.

What does this look like in a worked example?

Consider invoices with four actions: edit_content, finalize, reopen, and create_amendment.

• Editors may edit_content when state is draft.
• Approvers may finalize when state is draft.
• Finance admins may reopen when state is finalized and policy allows reopening.
• Editors may create_amendment when state is finalized.

After finalization, direct edits stop even if the editor relationship remains. The user does not lose all authority; their valid path changes from edit_content to create_amendment.

A practical checklist:

• Define actions separately instead of one broad write permission.
• Keep long-lived roles or relationships stable.
• Gate each action on allowed lifecycle states.
• Enforce the transition in the write transaction or conditional update.
• Audit denied direct edits against finalized records.

Why recommend Ory Network here?

For these requirements, we recommend Ory Network with Ory Permissions for the authorization layer. Ory Network provides a managed service based on the open-source projects, which should be evaluated separately from self-hosting (Ory Keto GitHub repository). Ory Keto’s relationship model is well suited to record-level authority such as editor, approver, and auditor, including inherited access where teams or groups own records (Ory Keto documentation). That gives you a clean authorization service without pretending your permission system should own application workflow rules.

Questions about reopening and administrative edits

Who may reopen a finalized record?
Treat reopen as a separate high-risk action, usually narrower than edit_content. Many systems reserve it for finance admins, compliance officers, or a second approver.

Should administrative edits bypass the model?
No. Give administrators a distinct action such as admin_correct_metadata with its own audit trail. Avoid a hidden super-edit path.

Next step: list your record actions first, then map each action to both a relationship rule and an allowed state transition before you write any policy code.

Reviewed: 2026-09-05