Summary

  • Atlassian's official example moves a Marketplace app on a 25-user Confluence Cloud subscription to a Teamwork Collection on the same site as 100 Jira users. The app then takes the 100-user price.
  • Collections count each person once across included products. Marketplace apps have their own licensing relationships, which can expand their chargeable population during the same purchase.
  • Instance billing, multi-instance subscriptions and Forge's early user-based model draw different boundaries. Buyers need the model available for their particular app and the partner's actual quote.

A small software tool can acquire 75 more people on its price list without winning 75 more enthusiasts. Sometimes the customer just buys a bigger bundle.

Atlassian provides a particularly useful example in its cloud-app billing instructions. A Marketplace app is installed on a Confluence Cloud subscription with 25 users. That subscription moves to a Teamwork Collection on the same site as a Jira subscription with 100 users. The app moves to the 100-user price.

The population behind the price has quadrupled. Calculating the money requires the app's price schedule, tiers and discounts. The purchasing consequence is already clear: the existing app needs a new quote before the bundle gets a signature.

The specialist team may have exactly the same job to do. Its tool may still serve that same job. The commercial boundary around the tool has grown. In software procurement, a change of address can come with a larger household to feed.

One person, counted once, inside one particular calculation

The Collection billing rules count a person who has access to at least one included app. Someone with access to several included apps counts once. The included products are consolidated under a Collection subscription on the invoice.

That is an intelligible pitch. A person who works in Jira and Confluence remains one person within the bundle's count. Procurement gets a combined purchase; finance gets a consolidated line. There is value in making the main contract easier to administer.

A Marketplace app brings its own licensing relationship. Atlassian ties its billing to the app's licence and the product on which it is installed, and explicitly explains that moving to a Collection can change pricing.

These two calculations can operate together. One removes duplicate counting across the bundle's included products. The other can enlarge the population attached to an additional tool. The bundle can count its people neatly while the specialist app starts charging against a wider circle.

A comparison of the main product quotes will show the first calculation. A list of installed apps, each priced after the move, reveals the second. The invoice can become shorter while the commercial homework remains quite long.

This matters particularly for a small department. It wanted a particular function, often within a shared environment chosen for the whole business. A platform consolidation decision made elsewhere can change the price basis of that function. The people explaining the tool's value and the people deciding the size of its environment may sit in different meetings.

The practical response is to put both purchases in the same meeting. The existing app portfolio is part of the bundle decision, even when the sales presentation gives it less space.

The licence sells a perimeter

The Forge licensing overview makes the standard model explicit: all users of the host instance are billed, regardless of how many actually use the app.

Its worked illustration has 500 Jira users and 50 actual app users. At an illustrative two dollars per user per month, the bill is $1,000. The example teaches the unit being sold. The host population supplies the quantity.

That creates a demanding sales problem for a specialist tool. It may do excellent work for 50 people, while its buyer has to justify a licence covering 500. The tool's usefulness and the fit of its commercial unit are separate parts of the purchasing argument.

A shared environment can have sound operational reasons to grow. Teams want common administration, easier collaboration and fewer disconnected systems. Under a host-wide app licence, that same environment supplies the commercial perimeter. An improvement in platform organisation can therefore enlarge the quantity behind a specialist app's price.

Jira apps also use a specific rule for counting across host Jira products. Atlassian's example with 100 Jira users and 80 Jira Service Management agents takes the larger number, 100. If the 100-user Jira subscription is deactivated, the remaining 80 become the price basis from the next billing cycle.

The noun after the number matters. These are host-product users counted under a licensing rule. Adding 100 and 80 would reconstruct the example incorrectly. Counting only people who opened the Marketplace app would answer another question entirely.

A procurement spreadsheet should consequently say which users it counts: people on a host product, people within an instance, unique people across a Collection, or people granted access to an individual app. Two columns labelled “users” can describe different groups with impressive numerical precision.

Marketplace billing cycles also match the parent product. Separating responsibility for the main platform and its add-ons does little to separate their commercial timing. A product move is an appropriate moment to price the attached tools, rather than leaving their owners to discover the consequences afterward.

A smaller circle needs a purchasable contract

Forge also describes user-based billing, where the count follows people granted access to the app. For a small team inside a large instance, the attraction is obvious: the licence can follow a more deliberately selected group.

The adoption guide places that model at a specific stage. Its early access programme allows building, deploying and testing in non-production environments through the Forge CLI. Marketplace publishing, pricing setup, revisions and approval are listed for later programme updates.

The same page contains prerequisites for published apps and language about moving existing customers. That mixture of development instructions and transition language leaves buyers needing a concrete answer from their partner: which billing model can it sell for this app and this customer today?

An administrator cannot create that offer merely by tightening an access group. The partner chooses whether to adopt the model, with one billing model per app. It can change prices in the transition. Existing customers follow the app's model change. Connect apps must adopt Forge to take this route.

There is an ordinary commercial negotiation inside the technical promise. A smaller billable population can come with a different per-user price. Procurement needs the complete offer: the new quantity, the new rate and the transition terms. Multiplying the old standard bill by the proportion of active users invents a quote the supplier has never made.

The proposed count also follows access granted. A person who has permission but does not open the app still belongs to that definition. Usage reports can inform the decision to grant access; they do not themselves replace the contractual population.

For buyers, the useful change would be a closer link between who is deliberately admitted to a tool and who enters its bill. For partners, it permits another way to package the tool's value. Both sides still have a price to agree.

Across instances is a separate question

Enterprise arrangements introduce another boundary: where an app is installed. Atlassian's Enterprise billing guide uses the fictional Acme company with 8,000 Jira users split between instances of 5,000 and 3,000. An instance-billed app installed on the 5,000-user instance takes that tier.

The architecture now has a visible commercial consequence. The company's total Jira population alone cannot reconstruct the app bill. The installation site and licensing model are part of the quantity.

A separate multi-instance Marketplace subscription for Jira and Confluence Cloud Enterprise consolidates app instances under an organisation subscription. It counts the same user once across those instances, with a user tier selected at the start. The app must still be installed on each required instance.

That arrangement addresses overlap between instances. Selecting people granted access within an instance addresses a different boundary. A buyer comparing the two needs to keep those questions separate, or risk assigning one model savings that belong to another.

The multi-instance page also says that all apps will offer the model. The purchase decision needs the concrete app's available offer. A marketplace's stated destination cannot fill in today's order form.

The result is a purchase with several dimensions: function, host product, installation location, user overlap, access and partner pricing. A good app can be worth buying under several arrangements. The buyer still needs to know which arrangement is on the table.

That is the value of Atlassian's small 25-to-100 example. It forces the conversation back to a quantity a purchasing team can recognise. Before arguing over the rate, establish who has just been brought inside it.