Inheritance and locks

Where does a setting get its value?

Every setting has a working default before anybody touches it. When you set a value, it applies to your level and to every level below you that has not set its own.

The platform looks for a value from the bottom up: first the instance, then its reseller, then the distributor. The first level that has set a value wins. If none has, the default applies.

An example. A reseller sets the Privacy policy URL to its own privacy policy. All of its instances now link to it, without anyone opening their settings. One instance belongs to a customer with a policy of its own and sets that address instead. Only that instance changes; the others keep the reseller's address, and if the reseller later moves its policy, they follow.

This is why a new instance works as soon as it exists: it inherits everything from the levels above it, and you set only what differs.

How do I stop a level below me from changing a setting?

When you open the white-label settings of a level below yours, for example a reseller opening one of its instances, every section shows an extra column: Overwritable?.

The Features section of an instance's white-label settings as its reseller sees it, with the Overwritable? switch in the right-hand column

  • Leave the switch on, and the administrators of that level may change the setting themselves.
  • Turn it off, and they see the setting greyed out with your value on their settings page and cannot change it there.

Your own settings page has no Overwritable? column. A setting that the level above has locked for you is shown greyed out, with the value set there.

Typical reasons to lock a setting:

  • The host name and the product name of a white-label trial, so the trial stays on the agreed address.
  • The email sender, when all instances must send through one mail server.
  • Legal links, when your contracts require your own privacy policy everywhere.
  • Features you sell separately, so an instance's administrators cannot switch them on themselves.

Does branding follow the same rules?

Branding is inherited the same way: an instance without its own logo shows its reseller's logo, and so on up the levels. Branding cannot be locked, though. Every level can replace the logo, the icon, the colors and the custom CSS for itself and the levels below it.

Two images are not inherited: the dark mode logo and the dark mode icon apply only to the level that uploaded them. An instance without its own dark mode logo uses its regular logo in dark mode.

Can accounts and users decide some things themselves?

Yes, for a few settings. Each of the following is a Yes/No setting in the white-label settings. When it is set to Yes, the decision moves one step further down:

SettingWho then decides
Can users change the authentication type for meetings?The meeting organizer, per meeting
Can users change the participant email setting?The meeting organizer, per meeting
Can users change the dark mode setting?Each user, for themselves
Can users change the scrollbar setting?Each user, for themselves
Can accounts override the meeting tag settings?The account administrator, for their account
Settings over-writable by accounts? (technical support add-on)The account administrator, for their account

The setting it belongs to is then only the default that applies until someone below changes it.

What is part of our agreement rather than a setting?

Some limits come from the agreement between your organization and us, not from the settings: how many rooms and meetings you can hand out to your accounts, how you pay and in which currency. A level can only pass down what it has itself. When you need more, talk to us.

Not sure how to best implement your project?

Contact our team to discuss the details.