A departing employee hands work to a colleague. The customer has paid for twenty seats, and an administrator wants to move one allocation without changing the agreement. That sounds like a small update. It is also a useful test of the whole seat model: whose identity changes, which capacity is freed, which access ends, and what evidence remains?
This guide treats seats as commercial allocations, not as user accounts or permanent permissions. It develops the boundaries a team needs before choosing an implementation. For the larger relationship between identity, billing, and licensing, start with the SaaS licensing architecture guide.
1. Define what a seat buys
“Twenty seats” is incomplete until the agreement defines the unit. Does it mean twenty named people may hold allocations? Twenty people may be connected at once? Twenty devices may activate? Those are different models. This guide concerns named-user allocations of organizational software access, not a concurrency meter or device-activation system.
A useful definition connects an organization, a license or package, and an external user. The license determines which capabilities may be distributed, how many allocations it permits, and when its rights are valid. An assignment records that one of those allocations belongs to a particular user.
Write the counting rule in ordinary language before creating a counter. For example: each unreleased assignment consumes one slot on this license. Then specify whether invitations reserve slots, how transfers work, and what expiration does to allocations. An agreement that is precise about price but vague about these transitions leaves engineering and support to invent commercial policy during an incident.
2. Give the organization a durable boundary
The company buying capacity should not depend on whichever employee first registered. That employee may leave, change roles, or stop using the product while the agreement continues. A durable organization boundary lets administrators and users change without transferring the commercial record between personal accounts.
Place licenses and allocations inside that boundary. Connect it to your application's customer record using an explicit identifier, and treat the display name as editable presentation. Avoid using a company's email domain as the sole proof of either identity or authority: a domain is not a substitute for an authorized customer relationship.
This does not necessarily require a new organization database. An existing company model may already do the job. The design question is whether it can consistently own licenses, scoped administration, and allocation history. Attaching seat limits, plan names, and company references independently to individual users makes those relationships harder to maintain.
Business Mode's Organization model is one concrete implementation, but the boundary matters independently of the provider.
3. Keep identity outside the seat ledger
Your authentication system owns the customer account, session, profile, and email relationship. A licensing layer normally needs a stable external user identifier, supplied by a trusted backend after authentication. It does not need to become another password store or duplicate customer directory.
Email illustrates why this separation matters. Changing an address should not create a new seat holder, and sending an invitation to an address does not automatically establish which application account will redeem it. The application must make that mapping deliberately. A seat-management screen may display an email for convenience while using an immutable account identifier underneath.
Define the identifier's scope as well as its format. A value unique inside one application may not be unique across integrations. Do not silently trim or lowercase opaque IDs during licensing operations unless that is already the application's canonical identity rule.
Account merging and deletion also deserve explicit workflows. Preserving assignment history does not mean retaining every profile field forever; avoiding profile duplication keeps those responsibilities easier to separate.
4. Model an assignment as a lifecycle record
A compact conceptual chain is organization → license → assignment → external user. The assignment is the relationship that changes when capacity is distributed. Give that relationship its own immutable identity rather than identifying it only by the current user and license.
Useful facts include the source license, external user, creation time, release state, and actor provenance. Enforce uniqueness for the simultaneous allocations your commercial model permits. In a one-seat-per-user-per-license design, a second active assignment for the same pair is a conflict, not another billable person. Historical released assignments can coexist with a later replacement.
Separate commands from summaries. “Release assignment A” names a specific lifecycle record. “Show this organization's members” asks for an aggregate over allocations. “How many seats are available?” asks about a particular capacity boundary. None requires turning an assignment into a user profile.
This separation makes support tooling more precise: operators can inspect the original allocation without assuming that the latest member row explains everything that happened.
5. Enforce capacity where the allocation commits
Consider two administrators looking at a license with nineteen of twenty seats allocated. Both screens show one available seat. Each submits a request for a different user. If the backend merely repeats a read-then-write check without protecting the invariant, both requests can observe the same capacity.
The authoritative operation must combine the eligibility decision and allocation under concurrency. The system owning the license must prevent committed allocations from exceeding its limit, according to its documented policy. The particular database mechanism is an implementation choice; a frontend counter cannot provide this guarantee.
This also applies to reducing capacity. Decide what happens when a proposed limit is below current usage. Rejecting that change, requiring releases first, and supporting an explicit overage policy are different commercial behaviors. Do not let an incidental database update choose among them.
Capacity displays remain valuable for planning. Label them as current observations, refresh after mutations, and give a useful response when another writer takes the final slot. A rejected allocation is not evidence that the earlier screen was fabricated; it may simply be stale.
6. Separate allocation from authorization
Allocation asks whether a customer user consumes a seat on a commercial license. Authorization asks whether that user may exercise a particular capability now. These are related questions, not interchangeable booleans.
A license may include analytics but not exports. Its validity may have ended. Another license may provide the same capability. An allocation can therefore remain operationally recorded while no longer supplying current access, or one allocation can disappear while another still authorizes the feature.
Use a capability-level decision at the point of use. A conceptual access chain is allocation → grant or provenance → effective authorization. The provenance explains why the right exists; the effective decision combines the sources that are currently valid. An optimized read model is useful only if it remains derived from those sources.
Do not use a historic successful assignment response as permanent permission. Also distinguish commercial authorization from application permissions: a valid analytics entitlement does not necessarily authorize viewing every organization's data. Your application still enforces the relevant data and action boundaries.
7. Count people and allocations separately
As a synthetic example, one employee holds an analytics license and a separate reporting license in the same organization. There are two commercial allocations and one external user. If both licenses include exports, there are also two sources of that capability, not two different people.
A member view can aggregate this into one row with an allocated-seat count. That is useful for roster management, but it should not replace the license-specific ledger. Releasing the analytics allocation may leave the reporting allocation and the member row intact.
Be explicit about the scope of every count shown to operators:
- License allocations describe usage of one agreement's seat capacity.
- Distinct organization users describe people with qualifying allocations in that organization.
- Current capability access describes users who satisfy a particular authorization rule now.
Those totals need not agree. Naming every dashboard number “active users” hides the difference and makes a legitimate result look like a synchronization bug.
8. Release and reassignment should preserve history
Return to the handover example. Assignment A belongs to the departing employee. Releasing A ends that allocation. Assignment B belongs to the replacement employee, or may later belong to the original employee again. B is a new lifecycle record; changing the user field on A would blur who held the allocation before and after the handover.
Immutable assignment identities also clarify delayed actions. A request to release A should still refer to A after B exists. It should not quietly mean “release whatever this person currently holds.” A bulk command defined by a set of user IDs has a different target: it may evaluate those users' current allocations when it runs.
This distinction matters when a response is lost. A delayed repeat of a user-targeted release can affect a replacement allocation. Reconcile current and historical state before deciding what to repeat. A generic retry wrapper cannot infer the operator's intent.
History supports explanation, not permission. A released allocation can remain queryable without continuing to grant access.
9. Expiration is a time boundary, not necessarily a deletion
A license's end date describes when its rights cease to be valid. Release describes an explicit allocation change. Your system may connect those transitions, but it should not confuse them.
One coherent design keeps allocations recorded after natural expiry while evaluating validity during authorization. Another may have a defined cleanup process. Either way, specify the effect on seat counters, member views, billing usage, and history. A background cleanup job should not be the only thing preventing expired commercial rights from authorizing use.
Start dates need the same care. If your model permits advance allocation, a scheduled agreement must not grant premature access. If it only permits allocation once active, make that restriction explicit to provisioning workflows. A stored seat row alone cannot answer the time question.
Explicit revocation is different again: an operator deliberately withdraws an agreement before or independently of its end. Define its cascading effects and reversibility. Calling all these actions “delete license” leaves the most important lifecycle behavior unspecified.
10. Reconcile overlapping sources of access
Suppose License A and License B both provide analytics to the same user. Releasing the assignment on A should remove A's contribution. If B remains valid, analytics access can remain. When the final valid contribution disappears, the capability should no longer be available.
This is a reconciliation problem, not a boolean toggle. An implementation that sets analytics to false on every seat release can remove rights supplied by another agreement. An implementation that only ever sets it to true can retain rights after all sources have ended.
Keep enough provenance to answer which assignment and license supplied each contribution. Then define one rule for combining valid sources. If you maintain an effective-access projection, changes must reconcile through that rule rather than letting unrelated workflows edit the projection independently.
Test both directions: remove one of several sources, then remove the final source. Include time-based expiry as well as explicit release. A happy-path assignment test cannot establish that the reverse transitions are correct.
11. Provisioning changes the handoff, not the allocation invariant
Different customers may reach the same seat model through different workflows. A backend may know the user immediately. An operator may upload a roster. An email invitation or redeemable code may let a user claim access later. A customer administrator may initiate distribution without knowing application IDs.
For each path, decide who authorizes the allocation, who authenticates the recipient, when capacity is consumed, and what repeating the request means. Sending an invitation is not inherently a reservation; if your system does reserve capacity, that reservation needs its own expiry and cancellation policy.
The final allocation rules should remain consistent across these entry points. A delegated administrator or bulk importer should not accidentally bypass constraints enforced by the direct backend path.
Keep credentials distinct from seats. Consuming an onboarding credential can be a historical event even after the resulting seat is released. Business Mode's Customer Provisioning guide covers its specific handoffs and replay behavior; those API mechanics are separate from choosing the architecture.
12. Separate license limits from broader commercial limits
A license seat limit controls one package's allocations. A provider may also impose a broader account limit on distinct organization users. These constraints count different things and can change independently.
In the two-license example, the employee consumes one seat on each license. Under a distinct-organization-user policy, the employee contributes one broader usage unit while either allocation remains. Releasing one seat frees that license's capacity without necessarily reducing the broader count. The same external user allocated in another organization may contribute another unit if organization is part of the counting identity.
That broader policy is not a universal rule for SaaS pricing. Some products choose other billing units. The architectural requirement is to write down the unit, scope, qualifying state, and release condition for each counter.
Reconcile usage from canonical allocation state rather than counting successful HTTP calls. Retries, reused allocations, and no-op releases make request totals unreliable as usage. Also avoid promising an invoice adjustment merely because an operational allocation count changed.
13. Treat bulk previews as planning tools
A roster preview can catch missing IDs, duplicates, malformed values, and likely capacity conflicts before an operator commits a large change. It is useful because it turns an opaque upload into a reviewable decision.
It is not automatically a reservation. The license can change while the operator reads the preview, another administrator can allocate seats, or a separate account-wide limit can block the final write. Specify exactly which constraints the preview evaluates; a green license-capacity indicator must not imply that every commercial constraint passed.
Define bulk mutation behavior explicitly. Does the operation commit all new allocations together, or report independent row outcomes? How are already-allocated users represented? An operator needs to distinguish a successful no-op from a rejected row without guessing from counts.
For destructive bulk work, make the target set and time semantics especially clear. A preview of user IDs does not freeze the assignment identities those users may hold later. The final operation and its recovery contract remain authoritative.
14. Preserve evidence after the write
A roster total does not answer who allocated a seat, why a release happened, or which integration performed it. Audit provenance should identify the actor, operation, resource, and time while avoiding unnecessary copies of sensitive user information.
Events solve a different problem: notifying another system that something changed. A robust integration needs durable event production, authenticated delivery, retry visibility, and idempotent receivers. A received release event is not automatically proof that all of a user's capabilities ended; it identifies a change whose consequences depend on remaining sources.
Plan for reconciliation when events are delayed, duplicated, or missed during consumer setup. Current-state reads and access checks remain necessary. Operators should be able to move from an unexpected access result to the underlying allocations, then to relevant audit and delivery records.
Do not turn every failure into “clear the cache and try again.” Sometimes the member remains because another allocation exists. A good operational model makes that explanation visible.
15. Recognize modeling shortcuts that change the question
Several shortcuts work only while requirements stay narrower than their names suggest:
- A single paid flag cannot describe different capability packages, validity windows, or which organization distributed access.
- Plan-name branches throughout product code tie feature enforcement to commercial naming.
- Email as seat identity makes address changes look like changes of person.
- Deleting released rows removes the identifiers needed to explain replacement allocations and delayed requests.
- Count-then-write checks without transactional protection cannot arbitrate concurrent claims on the last seat.
- Treating each seat as a unique billable user miscounts people with multiple allocations under a distinct-user policy.
- Treating assignment existence as final authorization ignores capability, time, revocation, and overlap.
These are not reasons to build every possible abstraction immediately. They are reasons to name a small model honestly. If the product truly sells one permanent capability to one individual, a simpler representation may fit. Do not assume that representation already answers organizational seat lifecycle questions.
16. Review a seat model with a concrete checklist
Before implementing or selecting infrastructure, work through these decisions with product and operations:
- What exact commercial unit does one seat represent, and which organization owns it?
- Which stable external identity receives the allocation, and who authenticates that user?
- Which simultaneous assignments are unique, and which historical records remain?
- Where is the capacity invariant enforced when two requests compete?
- How do expiry, revocation, and release differ for allocation, usage, and access?
- Can another valid license preserve the same capability?
- Does reassignment create a new immutable lifecycle identity?
- Which provisioning paths reserve capacity, if any, and when?
- What does a bulk preview check, and what can change before commit?
- After an uncertain write, which retained request or canonical record resolves the outcome?
- Can support identify the actor and trace the remaining sources of access?
Use one example customer and walk it through a handover, overlapping licenses, expiration, and an ambiguous bulk action. The exercise is more revealing than checking whether a system has a screen called Seats.
17. How Business Mode maps onto this model
Business Mode uses Organizations for customer boundaries, Licenses for distributable capabilities, capacity, and validity, and Assignments for allocations to stable external IDs. Grants preserve the source of Entitlements; Effective Entitlements provide the authorization projection queried through hasAccess.
Its member view aggregates unreleased allocations rather than creating another customer identity. License seat capacity and Workspace organization-user usage are separate measures. Those are explicit Business Mode semantics, not assumptions every vendor must share. See Members and seats and Access decisions for the definitions.
The Seat lifecycle implementation guide describes exact operations, preview limits, release recovery, and reconciliation. For product scope, explore Licensing; for the commercial counting model, review Pricing.
The next step is to test the model against your own agreements. The raw-HTTP Quickstart provides a small assignment-to-access workflow without asking you to move customer authentication.