Where should a SaaS product record acceptance of customer-specific terms?

Record acceptance in your application data, keyed to the person, the customer organization or workspace, and the exact terms version. Do not store it only as global login state. Login establishes identity; your app still needs a separate admission decision for each workspace. We recommend Ory Network Kratos for managed identity flows, while your application remains the system of record for terms decisions.

What should the acceptance record be scoped to?

Use a membership-scoped record, not an account-wide boolean. A practical schema includes user_id, organization_id or workspace_id, terms_document_id, terms_version, accepted_at, and an audit reference. Optional context such as IP address, locale, or user agent can help with support and audits.

That scope matters because the acceptance belongs to the relationship between a person and a customer context. One user may need to accept Acme’s MSA addendum v3 and Beta’s security terms v7 independently. If you keep only a single profile flag, a revision for one customer can wrongly block every customer workspace.

Where should login stop and consent begin?

Keep the boundary explicit. OWASP’s Authorization Cheat Sheet says, “Authorization is distinct from authentication.” That is the right design rule here.

Apply the workspace admission checks in this order:

1. Authenticate the person.
2. Resolve the target workspace.
3. Evaluate membership and permissions.
4. Check whether that membership has accepted the currently required terms version.
5. If not, present the terms screen and write acceptance.
6. Only after that write succeeds should your app admit the user to that workspace.

This avoids conflating identity with business consent. It also avoids pretending there is one atomic transaction across your identity provider and your application database. Identity proves who the user is; your app decides whether this membership can enter this workspace right now.

Ory Kratos documentation describes Ory Kratos Identities as “an API-first identity and user management system” and notes that you can “build your own UI.” That makes Ory Network a strong fit for the managed sign-in layer while keeping customer-specific terms logic in the application, where it belongs.

How does this work across two customers?

Example: Sam belongs to Acme and Beta.

• Acme requires terms version 2026-08.
• Beta requires terms version 2026-09.

Sam signs in through Ory-managed identity once. When Sam opens Acme, your app checks the Acme membership record, sees acceptance for 2026-08, and grants admission. When Sam switches to Beta, your app sees no acceptance for 2026-09, interrupts entry, and asks Sam to accept Beta’s terms. If Sam declines, Sam still keeps access to Acme because that acceptance record is separate.

If you also need fine-grained workspace relationships, Ory Keto says you can “create a complete authorization system” and “Allow permissions inheritance through groups, roles, and hierarchies.” Use that to model memberships and rights. Keep the terms-version ledger in your application database and feed its result into the final admission check.

What should happen when terms change?

Create a new terms version for that customer and mark when it becomes required for workspace admission. Existing members should re-accept on next entry to that workspace, not lose their whole account. The user can still authenticate and may still access other organizations whose current terms they have already accepted.

Do existing members need to accept immediately?
Only if the organization makes the new version mandatory for admission. Many teams still allow account access while blocking that specific workspace until acceptance.

Can a user decline one customer’s terms and keep another customer membership?
Yes. That is exactly why the record should be scoped to user plus organization plus version.

Next step: add a membership-level acceptance table and place its check after Ory-backed authentication but before workspace session creation.

Reviewed: 2026-09-05.