Quota Policies

Quota policies decide how many records of each type an installation may hold: how many analogue alarms, how many data transfers, how many custom menus. On a cloud installation they stop one tenant consuming another’s resources; on-premises they are a safety valve against a runaway script creating records by the thousand.

Columns

Column	Description
Policy	The record type (analogAlarm, dataTransfer, customMenu, …)
Default Limit	The default ceiling per space
Usage	How much is used now

Selecting a policy opens the Space Overrides panel below it.

Space overrides

Column	Description
Space	The space the override applies to
Limit	The limit in force for that space
Source	Where the limit comes from
Usage	That space’s usage

The default limit applies to every space; where one space needs a higher (or lower) one, an override is defined here.

An override is keyed by the space’s id, not its name

An override is tied to the space’s id. When these were once keyed by name, an override silently failed to apply if the name written did not match the space’s real name byte for byte — case, whitespace, punctuation. The name you type is now resolved to an id once, at the save; which is why renaming a space’s display name afterwards does not break the override.

Look at Usage first

When a user says they cannot create a record, compare that policy’s Usage against its Default Limit. A policy up against its ceiling is far quicker to spot there than in the error message.

How counting works

The counters live in the database and are locked while they are updated, so “check and increment” is one indivisible step. Two creations arriving at once cannot push past the limit together.

Related

• License — the installation-wide I/O and user limits
• Spaces — the spaces an override attaches to