Introduction

An organization is the top level container in Create. It owns the units, the users, the content and the branding, and it has its own web address and its own connection to an identity provider.

Organizations are created by Omnidocs, or by an operator for their own customers. Most of what you choose during creation can be changed afterwards. Four things cannot, so this page covers the whole dialog and calls out which decisions are permanent.

❗️
Permanent choices. The subdomain, the organization type, Only store claims in token and Anonymous users are fixed when the organization is created. Changing any of them later means creating a new organization and moving the content across. Only the name and the identity provider can be edited afterwards.

Name

The display name of the organization. It appears in the user interface for everyone who works in it.

This can be changed at any time afterwards.

Subdomain URL

The subdomain determines the address people use to reach Create, in the form https://[subdomain].omnidocs.cloud. The field shows the full resulting address next to the input, so you can see exactly what will be created before saving.

The rules are:

At least 3 characters.
Must start with a letter.
Letters, digits and hyphens only. No spaces, accented characters, dots or underscores.
It is saved in lower case regardless of how you type it.
It must be unique, and app is reserved.

When an operator creates a customer organization, the operator's own subdomain is added automatically as a suffix, separated by a hyphen. An organization acme created by the operator northstar becomes acme-northstar.omnidocs.cloud. This keeps addresses unique when two operators both have a customer called Acme.

The subdomain cannot be changed after creation. It is part of every bookmark your users keep and, more importantly, part of the redirect address registered with the identity provider, so changing it would break sign in. Choose it as carefully as you would a company domain.

Organization type

Option	What it is
Default (Create)	A standard organization on the new Create experience. This is the default.
Operator (Create)	An organization that can also create and manage customer organizations beneath it, and publish content to them. Used for partners and OEMs.
Create Classic	An organization on the Create Classic experience.

What it changes. The type decides which application your users get and which capabilities the organization has. Operator organizations gain the organization management screens, shared units and publishing, plus an extra permission level called Operate that does not exist elsewhere. Create Classic organizations get the Classic interface instead of the new one.

Two things to know. New organizations use the new Create experience by default, so pick Create Classic deliberately if that is what the customer needs. And an operator is always on the new experience: there is no operator plus Classic combination, which is why the dropdown offers three options rather than four.

The type cannot be changed after creation.

Identity provider

Create does not hold passwords. Every user signs in through the customer's own identity provider, which then tells Create who they are. You choose which kind here.

Option	Use it when
Microsoft Entra (OAuth 2.0)	The customer uses Microsoft Entra ID. This is the default and the most common choice.
OpenID Connect	Any other identity provider that speaks OpenID Connect, for example Keycloak, Okta or a national identity service.

The fields below the dropdown change with your choice.

Microsoft Entra (OAuth 2.0) asks for Tenant ID, Client ID and Scope ID. The customer's Azure administrator supplies these. See How to set up SSO for Microsoft Entra ID users for how they obtain them and the consent step that follows.

OpenID Connect asks for Discovery Endpoint (Metadata), Client ID, Client Secret, Scope ID, and offers one option:

Use offline_access scope
Leave this on unless the identity provider rejects it. It is on by default.

When it is on, Create asks the identity provider for permission to refresh the session quietly in the background, so people stay signed in through a working day without being sent back to the login screen. When it is off, Create does not ask for that permission, and users sign in again when their session expires.

The reason to turn it off is simple: some identity providers do not support the scope, or are configured to reject any request containing it, and sign in then fails outright. If the customer's provider is one of those, clear the checkbox. There is no other benefit to turning it off, and the cost is more frequent sign ins.

The identity provider and its settings can be changed later, which is the escape hatch if a customer migrates provider. Note that incorrect settings block sign in for the entire organization, so validate them with the customer before the first user tries.

See Authentication and OIDC for the difference between public and confidential clients and the redirect addresses to register.

Only store claims in token

What it is. When a user signs in, the identity provider sends Create a set of facts about them called claims: their name, their email, and whatever else the customer has configured, such as job title or department. Normally Create saves those claims against the user and refreshes them at each sign in. With this option ticked, Create does not save them at all.

What happens instead. The claims travel with the user's session and are read at the moment a document is generated. Nothing about them is written down. When the session ends, nothing is left behind.

How it shows in the application. Templates that use claims keep working, because the values are still there while the user is signed in. What disappears is everything that depends on Create having the claims saved:

The Claims screen under User identity is hidden, so form fields cannot be pre-filled with claim values. Users do not see their own details in the form, though those details still appear in the finished document.
Automatic role assignment is hidden in the role dialog, because the criteria are evaluated against saved claims. Roles are assigned by hand.
The claim columns of the User Identities data source are empty. Profile columns still work.
Documents generated through the API or by an integration have no claims available, because there is no signed in person whose session can be read.

Why you would set it. Some customers are not allowed to keep employee details in a supplier's system. A public authority whose security team requires that no employee register exists outside their own systems is the typical case, and a data processing agreement that permits an email address for sign in but nothing further is the typical trigger. This option lets Create work for them: people sign in, permissions work, documents are still personalized, and no directory data is retained.

Anonymous users

What it is. Instead of saving the display name the identity provider sends, Create stores and shows the person as Anonymous (email), for example Anonymous ([email protected]). This is applied fresh at every sign in.

How it shows in the application. Everywhere Create would normally show who someone is or who did something:

The Users list, and the role and permission dialogs.
Created by and Last modified by on recipes, content sources and other items.
The documents overview.

What is kept. The real name is still available while generating a document, so templates can print it in a signature block. The email address stays, because that is what makes sign in and permissions work. Anonymous here means the name is not kept, not that the person is unidentifiable.

Users whose identity provider sends no display name at all are shown as anonymous in every organization, whether or not this option is ticked.

Why you would set it. The same family of reasons as the previous option, one step further: the customer accepts that Create knows an email address, but does not want a browsable list of employee names sitting in a supplier system. Ticking both options together keeps the name out of Create entirely.

Invite an organization admin?

Tick this and enter an email address to invite the first administrator as part of creating the organization.

That person is given full management access to the organization, and for an operator organization they also receive operator access, so they can start creating customer organizations straight away. They receive an invitation and become a normal user of the organization on first sign in.

You can leave this unticked and invite administrators later from within the organization. Inviting one now is simply the quickest way to hand a finished organization over.

After creation

The organization exists immediately and is reachable at its subdomain. Before handing it over:

Check that sign in works, ideally with a real user from the customer's directory. A wrong identity provider setting blocks everyone, and it is the one significant setting you can still correct.
Confirm branding, which an operator's customer organizations inherit from the operator.
Set up units, roles and content sources for the way the customer works.