Custom Tenant Information Fields

Tenant fields hold your own attributes against each customer organisation in a multi-tenant installation.

Where to find it

Architect Panel → Configuration:

• Custom User Information Fields — fields on user records
• Custom Tenant Information Fields — fields on tenant records
• Instance Configuration Fields — fields on the installation itself

Architect Panel → Configuration:

• Multitenancy — the tenants themselves

What belongs here

Facts about the customer as a tenant of your platform: their account manager, their sector, a contract reference, their onboarding date, a support tier.

These are things you know about them because they are your customer, and they are the same for everybody within that tenant.

What does not

• Their business data. That lives in their own datastores and is theirs.
• Anything varying within the tenant. If it differs by person, it is a user field.
• Your CRM. If you are tracking opportunities, renewals and contacts against customers, that is a datastore with relationships — not a growing set of fields on a tenant record.

The third is the common drift. Tenant fields are convenient, so commercial information accumulates there until somebody wants to report on renewals and finds it cannot be done.

They are yours, not the customer’s

An important distinction. These are your notes about a customer, which may include things you would not choose to show them — a support tier, an internal risk rating, an account manager's assessment.

Be deliberate about whether any are visible within the tenant, and default to not.

Useful for driving behaviour

A tenant field can shape how the platform behaves for that customer — which template they get, which branding, which options are offered. That is a legitimate and powerful use.

What it should not do is grant access. Entitlement comes from their subscription package; a tenant field describing their tier is a description, and anything granting features from it duplicates the package with something that can silently disagree.

Keep the set small

Every field is one somebody must populate for every new tenant, and an unpopulated field is a gap in whatever depends on it. Add what you will actually use.

Populate at onboarding

Because retrofitting means going back through every existing tenant, guessing. Make the fields part of the onboarding checklist rather than something filled in later.

Worked example

A platform holds account manager, sector, onboarding date and support tier as tenant fields, all populated at onboarding and none visible to the customer. Renewals and opportunities are a datastore linked to the tenant, because those needed dates, owners and reporting that fields could not carry.

Recommendations

• Facts about the tenant as your customer, nothing else.
• Use a datastore once commercial data needs reporting.
• Never grant features from a tenant field.
• Populate at onboarding, not retrospectively.