Understand the tenant model

Tenants, apps and markets

The four ideas the rest of the platform hangs off — and why everything you already use is an app.

Four words explain almost every question that starts with "where do I change this?": tenant, app, subscription and market. They are worth twenty minutes, because most administration confusion is one of these four being mistaken for another.

Your tenant is your company

A tenant is one company. Yours. It has a fixed, readable identifier, a slug like max-mueller-gmbh, that follows your data everywhere it goes: in the database, in the login system, in URLs, in logs, in the support case somebody opens on your behalf. The identifier is set when the tenant is provisioned and does not change afterwards, so pick a name you can live with.

The platform is multi-tenant: the same software serves every customer. Your data is not in a separate copy of the application, and it is also not mixed in with anyone else's. The database enforces the isolation, one layer below the software: every table carries the tenant identifier, and every query is filtered against the identifier in your session before the application sees a row. This is not a rule an app has to remember to apply. An app cannot forget it, and a badly written app cannot work around it.

Where the tenant boundary is not. A tenant is not a shop and not a country. One tenant can run several storefronts, several markets, several brands. If you are wondering whether your Austrian subsidiary needs its own tenant, the answer is almost always no. It needs a market. Separate tenants means separate catalogs, separate customers and separate bills, with no shared reporting.

Everything is an app, including what is already there

This is the idea that surprises people. Products, Prices, Orders, Customers, Markets, the things that were there on your first day, are not "the platform" with apps bolted on the side. They are apps, built the same way as anything you add later, installed into your tenant when it was provisioned.

An app is self-contained and declares what it is in a handful of files:

FileWhat it declares
manifest.jsonIdentity, version, dependencies, and the permissions the app needs
schema.jsonThe tables it owns: its data model
cockpit.jsonWhat it adds to the Cockpit: navigation entries, screens, dashboard widgets, buttons
settings.jsonIts configuration, per tenant and per market
billing.jsonHow it is sold: included, free, or paid

Two consequences you notice in daily work:

The Cockpit's navigation is assembled, not fixed. The menu you see is the sum of the apps installed in your tenant. Install an app and new entries appear; uninstall it and they go. If a colleague's Cockpit has a menu item yours does not, the difference is an installed app or a permission, not a bug.

Apps have no access by default. An app declares, in its manifest, every entity it reads and writes and every capability it needs: outbound network access to a named host, event subscriptions, storage. That declaration is visible on the app as its Access register, and it is worth reading. An app asking for write access to prices is telling you something you should decide on rather than scroll past.

You approve access explicitly when an app update asks for more than it had. Until you approve, your tenant keeps running the version you already consented to. See Apps and the Marketplace.

Apps come in three kinds, and the distinction shows up on your invoice:

KindWhere it comes fromPricing shown as
IncludedCore apps that come with your subscriptionIncluded
PublicThe App Marketplace, from revenexx or an approved partnerFree or Paid
PrivateBuilt for your company alone, by you or your partnerNot listed publicly

Your subscription decides what is included

Your subscription is a plan. Apps marked Included are the ones that come with it; the Marketplace adds capability on top, either free or on its own subscription line.

This is the answer to "the documentation describes a screen I do not have". Three possible causes, in the order worth checking: the app is not installed, your subscription does not include it, or your access does not permit it. See Subscription and billing and Users, roles and permissions.

Markets are business contexts inside your tenant

A market is a distinct commercial context within your one tenant: a country, a region, a brand, a B2C offshoot of a B2B business. Each market has its own base currency, its own locales, the currencies it trades in, and its own tax classes. You manage them under Commerce Studio › Configuration › Markets, with the tabs Overview, Currencies and Tax classes.

Markets are provided by a core app that is on every tenant by default, and it does one structural thing: it gives every other app a dimension to slice data by. Products, prices, customers, orders and customer metrics can all be scoped per market. That is why a market is the right answer for the Austrian subsidiary. You get separate currency, tax and assortment handling while keeping one catalog, one customer base and one set of reports.

You switch the market you are working in from the top bar of the Cockpit. The default is Global, which is not a market at all. It is the tenant-wide baseline that every market inherits from until it overrides something. App settings work the same way: a field is either global, or market-scoped and able to override the baseline.

Market, channel, storefront. They are three different things and are often confused. A market is a commercial context with its own currency and tax. A channel is a route data or an order travels by: a shop, a punchout connection, phone orders keyed by the Innendienst. A storefront is a website. One market can have several storefronts; one storefront serves one market.

The distinction that catches everyone

There are two separate sets of people with two separate sets of roles, and confusing them is the most common mistake in this area.

Your teamYour customers' buyers
WhoYour colleagues: admins, product managers, InnendienstPurchasers at the companies that buy from you
Where they log inThe Cockpit, through Revenexx SSOYour storefront
Who manages themYou, under Settings › TeamYou, under CRM › Contacts, per customer organization
What roles controlWhich Cockpit screens and actions they getWhether a buyer may see prices, order, or approve (CRM › Roles)
Documented inUsers, roles and permissionsContacts and roles

They share no accounts, no login, and no role definitions. Giving a colleague access to the Cockpit gives them nothing in your shop. Giving a buyer an approver role in a customer organization gives them nothing in the Cockpit.

Next