Team Licenses for Software: Seats, Devices and Self-Service

A team license for software needs a clear unit: five people, five registered devices or five simultaneous sessions. State that unit at checkout and enforce the corresponding control in the application. Sharing one key with an undefined limit creates support problems as soon as someone uses two laptops or changes jobs.

This guide describes existing PermitCore license, Store and customer-portal controls. It separates a fixed device-seat pack from a complete organisation-membership system or an automatic per-seat billing workflow.

Define what one seat buys

• Registered devices. A node-locked key with five activations can register five distinct device IDs. One person using two devices can use two slots.
• Concurrent sessions. A floating license limits active sessions. The application checks out a session, heartbeats it and checks it in. This measures simultaneous use rather than the number of registered people.
• Named people. Define an individual entitlement and an authenticated user mapping when the commercial unit is a person. A device counter alone cannot prove how many people use the software.

Describe allowed workstations, shared computers and remote sessions in your own sales terms. A license feature or customer email is not a substitute for authenticating a person. See node-locked and floating models before choosing the cap.

Keep the three capacity counters separate

Per-key capacity belongs to an individual license. For a registered-device model, maxActivations is that key's limit and currentActivations records its usage. Your buyer's five-device pack does not become an account-wide five-customer plan.

The monthly activation pool belongs to your PermitCore vendor account and covers qualifying activation records across customers during the billing period. Issuing a key and validating an existing installation do not consume a new entry. Same-device node-locked reactivation reuses its seat; repeatedly calling count-based activation can consume additional capacity. Review the actual account usage in Billing.

PermitCore team members are users who can access your administration account under its roles and permissions. They are separate from your software buyers and from the device or session seats you sell. Inviting a colleague to your admin panel does not assign them a customer's software license.

The activation limits reference explains these counters, including SeatsExhausted and PoolExhausted. A new billing period does not clear devices already registered to customer keys.

Example: a fixed five-device Store pack

1. Create or choose the underlying software product.
2. Create a Store listing whose title and description explicitly say “five registered devices”.
3. Configure its generated license for five activations and enable node locking. Set the features and one-time, monthly or annual price you intend to sell.
4. Use your selected Stripe or Paddle connection and prepare the matching catalog price. One saved provider powers the entire Store.
5. Complete a test purchase and inspect the issued key: correct product, five-device cap, features and billing period.
6. Activate distinct test devices through your app. Check capacity handling, same-device reactivation and authorised removal before inviting buyers.

This example sells one key with a fixed device cap. It does not create five employee accounts. The app must activate an installation at the appropriate point and handle rejected capacity checks; a successful key validation alone does not register a device or reserve a floating session.

For recurring purchases, verified paid renewals extend the original key. Grace and final cancellation follow the Store subscription rules. The payment lifecycle guide explains the payment evidence and refund boundaries.

Let the right person release a device

The customer portal can show a license's activations and remove a device. A signed-in customer account is restricted to licenses linked to that customer; it is not a view of every license belonging to your company. A buyer can then register the replacement device using the same key, subject to its remaining capacity and validity.

Choose who should have that authority. In the default key-only portal mode, the key holder can use its self-service controls. For a shared team key, that may be broader authority than you want every employee to have. Where your plan supports them, email-code or account-required policies provide stronger portal access controls. Link the correct customer contact or account before enforcing the stronger policy.

These controls manage license and device ownership. They do not supply a full customer organisation directory with delegated coworker invitations and per-person seat assignment. Build that workflow in your application if your product needs it, or issue individual entitlements through your supported administration process.

Removing a registration frees the key's capacity; it does not remotely uninstall a copy. Your application must enforce its registration or session rules. Previously issued offline proofs keep their signed constraints until expiry or reconnect, so a transfer is not a promise of instantaneous offline revocation.

Plan an upgrade from five to ten seats

Changing a Store listing's generated-license settings affects its issuance configuration. It does not automatically rewrite the cap on keys already issued. An authorised vendor can update an existing license's activation cap without replacing its key; the update rejects a cap below its current activation count.

Handle billing and entitlement as a coordinated workflow: agree the new unit and effective time, establish the required payment or contractual authorisation, then update the correct license. Record what changed. A fixed pack can be a straightforward starting point; the current Store does not provide a general buyer-facing seat-quantity and proration wizard.

Stripe's proration documentation describes credits, charges and timing when subscriptions change. A calculated positive adjustment is not necessarily an immediately collected payment, and a negative adjustment is not automatically a cash refund. Do not assume a provider price change by itself updates a PermitCore seat cap.

Likewise, a Paddle card update or credit-only subscription change is not a paid seat upgrade. If you build a custom quantity-based flow, test unpaid changes, duplicate events, downgrade timing and the actual entitlement update together.

Make the buyer's administration simple

Show the purchased unit, cap, support or upgrade terms and renewal schedule before checkout. Tell the buyer where to find its order, provider document and license, who can remove devices, and how to request more capacity. For Paddle merchant-of-record purchases, use the provider-issued document rather than inventing a separate seller invoice.

A single team key is convenient for a trusted deployment process, but every extra recipient is another holder of that credential. Keep keys out of public tickets and source repositories. Use individual identities when you need an audit trail about people; a device name or reported email is not identity proof. See key-sharing boundaries and the transfer guide.

Test the policy you actually sell

• A fresh device consumes the expected slot; same-device node-locked reactivation reuses it.
• A full key returns a capacity failure that the app handles; another customer's key grants no access to the wrong product.
• An authorised customer can remove its own device; another account cannot remove it.
• A replacement follows the chosen registration flow and retains the intended key, features and expiry.
• A seat-cap update does not change the encrypted key or silently replace the billing agreement.
• Expired, revoked, offline and concurrent-session outcomes match the policy explained to the buyer.

The five-device pack is a configuration example. Choose the controls available on your plan, verify the application flow and keep the buyer's meaning of “seat” explicit.