A new payer does not require a new person
Someone subscribes to a learning app for personal use. Later, their employer buys access to the same library for its staff. The person now has two possible reasons to use a feature, but still has one profile, one set of saved items and one account they recognize.
This is an example, not a customer case study. It illustrates a product-policy question that appears whenever a consumer or self-service product adds company-paid access: how should the new source relate to what the person already has?
The clean starting point is to separate identity, access and charging. Identity tells you who is signed in. Access tells you what that person may use now. Charging tells you which commercial arrangement collects payment. Those concerns interact, but none can safely stand in for all the others.
Preserve the sources instead of replacing the account type
Avoid converting a person from “individual” to “company user” as though the two were mutually exclusive identities. A person can qualify through a personal subscription, a company agreement or both. They may also hold several company allocations that include different capabilities.
Represent each source with enough information to decide whether it is valid and explain where it came from. That usually includes the owner of the source, its included features, relevant dates and its relationship to the user. Keep a reference to the authoritative record rather than copying a permanent “paid” answer into several unrelated places.
For example, your existing billing integration may answer whether the personal subscription includes the premium library. A company-access service may answer whether the same user currently receives that library through a valid company allocation. Your application can then apply its policy to those answers.
The user-facing label does not need to expose this internal structure. “Provided by your company” may be enough to explain the current source. Your support tools need more detail so they can distinguish a subscription problem from a released seat.
Decide coexistence feature by feature
A common policy for a shared feature is that either valid source provides access. Under that policy:
- Personal subscription only: the feature remains available through personal access.
- Company access only: the feature is available through the company’s agreement.
- Both valid: the person can use the feature without needing a second account.
- Personal access ends: check whether valid company access remains.
- Company access ends: check whether valid personal access remains.
- Neither source valid: the feature is no longer available under this policy.
This is a policy example, not a universal rule. A company might purchase a particular course collection while a personal subscription includes a different one. Evaluate the capability being requested rather than assuming that every paid arrangement means the same thing.
Keep other product restrictions explicit. A feature entitlement is not automatically permission to see every customer’s documents or administer a company. Company-provided access can enable functionality without granting access to company-owned data. If your product has workspace or data-ownership boundaries, those checks remain your application’s responsibility.
The Feature access product page explains how a stable capability can remain separate from the package that includes it. The value of that separation is clearest when packages overlap without being identical.
Billing policy is a separate conversation
If someone receives a company-funded place, should their personal subscription keep renewing? Possible product policies include keeping it unchanged, offering a voluntary cancellation path or scheduling a change at the next renewal. The right choice depends on the offer and on the billing channels your product actually supports.
Do not let a seat-assignment event silently decide that policy. The person may want personal access after leaving the company, or the two arrangements may include different features. A company administrator changing a roster should not automatically gain authority to alter an employee’s personal payment arrangement.
Explain the policy before someone confirms company access. Separate statements such as “Your company now provides this feature” from “Your personal subscription will stop renewing.” The first does not prove the second. Any cancellation or refund must be performed and confirmed through the system that owns it.
Also distinguish a company’s payment status from each person’s access. Your commercial policy may specify dates or a grace period, but those must be deliberately represented by your integration. Do not infer that a browser returning from a payment page has completed every downstream access change.
Connect the claim to the authenticated account
The application should authenticate the person before connecting a company invitation, code or direct allocation to their stable user ID. The user ID is the integration identity. The invitation email is a delivery destination and part of the claim flow, not a reason to create a parallel person record.
People may use a personal address for an existing account and receive a work invitation at another address. Your product needs a deliberate claim policy for that situation. Show which account is about to receive access and provide an appropriate route to switch accounts or verify ownership. Do not automatically merge accounts just because the names look similar.
The same care applies to invitations opened on another device. Preserve the claim through the legitimate sign-in flow without exposing it in analytics or public URLs beyond the required handoff. A claim token proves possession of a provisioning credential; it is not a substitute for your application establishing who will receive the seat.
Keep account recovery under the identity system that already owns the account. Losing a work mailbox, losing a company seat and forgetting a password are different problems. Combining them into a new “business account” can make a routine departure much more disruptive than the access change itself.
Expiration should remove a source, not erase a person
A company agreement reaching its end date means that agreement no longer provides access under its validity rules. It does not mean the user’s profile should disappear. Saved preferences, personal purchases and access from other sources need their own lifecycle policies.
Similarly, releasing a seat should remove the company allocation it targets. It should not indiscriminately remove every reason the person can use the product. If another company agreement or a personal subscription still provides the capability, the final access decision should consider it.
Keep the events distinct:
- Expiration ends validity at the configured time.
- Revocation explicitly ends a source according to its rules.
- Seat release removes a particular allocation.
- Personal cancellation changes a subscription according to the billing policy.
- Account deletion is a separate identity and data-lifecycle operation.
These distinctions also help the interface explain what happened. “Your company access ended” is more accurate than “Your account has expired” when the account still exists and the person could continue personally.
Do not promise immediate propagation without defining the path. If your application caches access decisions, it must decide how long stale answers are acceptable and how to recover after an event is missed. A signed webhook is useful notification, but it does not eliminate the need for reconciliation with authoritative state.
Give the backend one deliberate decision point
Keep feature authorization behind a small application-owned boundary. That boundary identifies the signed-in user, asks the relevant access sources about the requested feature and applies the product’s combination policy. Protected server actions should enforce the result rather than relying only on what the client displays.
Conceptually, the flow is: authenticate the existing account, resolve personal access, resolve company access, then decide whether the feature is allowed. The order and number of calls are implementation choices. What matters is that the final answer has a defined owner and can be explained from current sources.
For an either-source policy, a confirmed valid personal subscription may be enough for that feature even if a company-access lookup is temporarily unavailable. If no valid source is known and another source cannot be checked, decide how the application handles that uncertainty. An unavailable provider is not the same fact as a confirmed negative access result.
Keep credentials on the backend. A mobile or browser application should not receive the machine key needed to query or mutate company access. It can ask your own application server, which already knows the authenticated person and the action they are attempting.
For Business Mode-specific request semantics, use the access-decision concepts and Quickstart. This guide describes the product boundary rather than prescribing a universal caching strategy or availability policy.
Make the support explanation match the decision
Support needs to answer both “Can this person use the feature?” and “Why?” A single current boolean answers only the first question, and even that answer becomes unreliable if no one knows when it was calculated.
Retain the relationship to the relevant personal subscription or company allocation. Record changes with the actor, affected source and time where your systems support it. Do not overwrite the old source simply because another source now grants the same capability.
Only expose information appropriate to the person asking. A company administrator needs to manage the company’s seats, not inspect an employee’s personal card, private activity or unrelated memberships. Operational provenance for your support team and customer-visible roster information are different views of the system.
This is a design boundary, not a claim that an access service manages your privacy policy for you. Your application decides what to store, what each role may see and how to explain those choices to users.
Introduce coexistence without a wholesale identity migration
Start by documenting the current personal-access rule. Identify the stable user key and the feature boundary where your application enforces it. Then add the company source alongside it for a controlled offer rather than replacing all existing subscription logic at once.
Use a small test matrix before broad rollout:
- A personal subscriber accepts company access on the existing account.
- A person without a subscription receives company access.
- Personal access ends while company access remains valid.
- Company access ends while personal access remains valid.
- Both sources end, leaving neither valid.
- Two company allocations overlap and only one is released.
- A claim is attempted on the wrong account or after capacity is exhausted.
- A source lookup is unavailable rather than returning a negative answer.
These cases exercise the boundary between systems, not just the happy-path invitation screen. Include support and user-facing explanations in the review: a correct backend answer can still produce a confusing experience if the page says “subscription cancelled” when only a company seat was released.
Where practical, compare the combined decision with existing behavior before enabling it for a broader audience. Keep a record of deliberate policy differences. Rolling back the integration should not require deleting accounts or rewriting personal billing history; it should have a defined effect on the new company-access path.
What Business Mode owns in this model
Business Mode can represent a company’s access terms as a License containing included Entitlements, capacity and validity. An Assignment allocates a seat to an external user ID. Grants record where company access comes from, and the access check answers whether that user currently has the requested Entitlement within the Project.
If one Assignment is released, Business Mode removes its Grants and reconciles remaining sources. Another valid License can still provide the feature. That is company-side reconciliation; Business Mode does not automatically ingest or cancel personal subscriptions held in your existing billing system.
Your backend therefore combines two responsibilities: Business Mode resolves its company-access state, and your existing system resolves personal access. Your application owns the policy that joins them. A shared stable user ID lets you do that without replacing authentication or creating a second profile for the same person.
For the commercial view, explore selling a consumer app to companies. For the deeper allocation rules, read the seat lifecycle guide. The useful outcome is simple: a change in who pays need not force a change in who the user is.