One code. A clear way into your product.
A company is ready to launch your learning app to 100 employees. A partner wants to include your premium library in a membership offer. A pilot group needs access until the end of November. In each case, you need a simple way for people to claim the access you have agreed to provide.
These are illustrative examples, not customer stories. The useful part is the same: people sign in to your existing app, enter a code and receive access under a defined agreement. Their account, saved work and familiar product experience stay where they are.
BusinessMode lets you choose a memorable promo string for an Access Code. The code connects to a License with its own features, seats and validity dates. Your app provides the redemption screen; BusinessMode handles the allocation and current company-access decision behind it.
Start with the access you want to offer
A promo code is easiest to explain when the offer is specific. “Try our premium courses until 30 November” tells someone more than “unlock Premium.” Decide what is included, who the offer is intended for, how many people may claim it and when the access ends.
In BusinessMode, an Organization represents the customer or group. A License holds the included Entitlements, seat capacity and access dates. You create the code against that License. Several codes can lead to the same License, but they share its available seats.
These codes grant product access. They do not apply a percentage discount, reduce an invoice or change a Stripe subscription. If your offer also includes a price promotion, configure that separately in the system that owns the payment.
Use codes where a shared invitation fits
Launch company access
Give an authorized customer administrator a code to share through the company's own onboarding channel. Employees claim a place after signing in to your app, so you do not need to create a second account for each person.
Run a fixed-term pilot
Give a small group access to a defined set of features for a shared evaluation period. A License ending on 30 November gives the group the same end date. It does not automatically give every person 30 days from their individual redemption date; a rolling trial needs a separate provisioning workflow.
Support a partner or membership offer
A partner can distribute a code alongside its own offer. Use an appropriate Organization and License to keep the access arrangement clear, and set a lifetime redemption limit where the number of claims matters.
Welcome an event or learning cohort
Let an invited group claim a course library or product capability without collecting every user ID in advance. Set the claim deadline separately from the period during which the group can use the product.
A shared code can be forwarded. Possession of it does not prove employment, membership or attendance. If those checks matter, enforce them in your own backend before redemption or use a more targeted invitation workflow.
Give the offer a name people can type
When creating an Access Code, enter the optional promo code you want people to use. An illustrative value such as NOVEMBER_ACCESS is used exactly as entered. Leaving the field blank creates the usual generated bmac_… code instead. Existing generated codes continue to work.
Matching is case-sensitive. Spaces and other characters are significant, so keep the value easy to communicate and let people copy it. The code's internal name is a separate label for your team.
A value must be unique within a Project, including across its Organizations and Licenses. Expired or revoked values remain reserved in that Project. Use a new value for a later offer. Save the full code when you create it; ordinary list views show display metadata rather than revealing it again.
Set the claim window and the access window separately
The code's expiry controls when a new person can redeem it. The License's dates control when its access is valid. For example, you can close claims on 10 November while letting people who already claimed continue using the included features until 30 November.
New redemption also requires an active License and enough capacity for any new allocation. Distributing a code does not reserve a seat. If your team fills the last places through another code, an invitation or direct assignment, a later claim may fail.
Revoking a code stops new claims through that code. It does not remove seats already assigned through earlier redemptions. To end existing access, manage the relevant assignment or License and consider any other valid access the person holds.
Keep redemption limits separate from seats
Three limits can affect an offer: available seats on the License, organization-user capacity in your BusinessMode Workspace, and the code's own lifetime redemption limit. A code without a redemption cap still respects the other limits.
A successful first use by a user consumes one redemption even if that user already holds a seat on the target License. Repeating that same user's successful redemption returns its original result and does not consume another code use.
Releasing a seat can make allocation capacity available, but it does not replenish the code's lifetime uses. If a user's original seat has been released, redeeming the same code again returns the earlier redemption; it does not restore the seat. Use an appropriate new provisioning action when someone needs access again.
This distinction makes campaign rules easier to explain: “up to 100 people may claim this code” and “up to 100 seats may be allocated at once” describe different limits.
Let your app own the sign-in and redemption experience
Add a code field where it fits your product: during onboarding, in account settings or on an offer page. The person signs in through your existing authentication system. Your backend takes their verified user ID and submits the exact code to BusinessMode with your server-side Project credential.
Keep that credential out of the browser. Avoid putting redeemable codes in URLs, analytics events or ordinary logs. Explain expired offers, exhausted codes and unavailable seats in language the person can act on.
After redemption, check current feature access when the protected feature is used. A redemption receipt records what happened; it is not a permanent authorization decision. Your backend can combine valid company access with a personal subscription according to your own product policy.
Claiming a code does not automatically cancel, refund or pause a personal subscription. If you want to offer that choice, explain it and implement it through your billing system.
Give customer administrators the right scope
Project developers and authorized Organization administrators can create codes. A customer administrator works within their Organization and its Licenses; this does not give them your Project API credentials or permission to change commercial limits.
Your team defines the offer. The customer can handle distribution and supported seat management. That is useful when the next joiner should not need a support ticket from your team.
Start with one offer and follow it through
- Choose one Organization, one License and the features you want to include.
- Set the License's dates and seats, then create a code with the appropriate claim deadline and lifetime limit.
- Connect redemption to your existing authenticated user flow.
- Test a successful claim, a repeat claim, expiry, exhausted capacity and seat release.
- Check current feature access and make the offer's limits clear before distributing it.
BusinessMode provides the access model, code redemption, seat allocation and administration. Your product keeps the experience people use and the commercial decisions behind the offer.
Read the customer provisioning guide for the integration details, explore customer administration, or follow the Quickstart to connect your first access check.