Platform settings (properties) — user guide
This guide explains how to change the values the platform runs on — your facility's currency, an integration address, a retention window — without waiting for a software release.
Who this is for: platform administrators, and facility administrators who tune their own facility's behaviour.
Where: Administration → Properties (/admin/platform/properties).
1. What a property is
A property is a named value the software reads while it runs. billing.default_currency with
the value NGN tells the billing screens which currency to price in. Names are dotted and start
with the area they belong to, so they sort together and read plainly.
A property is not a feature flag. A flag answers is this behaviour switched on?; a property answers what value does that behaviour use? Flags live on their own screen.
2. The three scopes, and why the same name appears more than once
Every property belongs to one of three levels:
| Scope | Applies to | Typical use |
|---|---|---|
| Whole platform | Every tenant and facility in the deployment | The sensible default the software ships with |
| Whole tenant | Every facility of one organisation | A ministry or hospital group's house standard |
| This facility | One facility only | The exception a single site needs |
The same name may exist at all three levels at once, and that is the point. When the software
asks for a value it takes the most specific one that exists: your facility's, otherwise your
tenant's, otherwise the platform's. So a group can set billing.default_currency = NGN once for
all its hospitals, and the one clinic operating across a border sets XOF for itself without
disturbing anyone.
What you cannot do is create the same name twice at the same level — that would leave two answers to one question, and the system refuses it.
3. Setting a value
- Open Administration → Properties. The list shows every property that applies to you, each labelled with the scope it came from.
- + Add property, then give it a name, a value, and — most important — the scope. Choose This facility unless you intend to change behaviour for everyone below you.
- Save. The change takes effect the next time the software reads the setting; no restart.
To change a value, use Edit — the name and scope are fixed once created, because they are what identifies the setting. If you need a different name, create a different property.
4. Removing an override restores what it covered
Deleting a facility property does not delete the setting. It removes your override, so the tenant or platform value applies again — the value you had before someone tailored it. This is why "delete" is safe on an override and worth thinking twice about at platform level, where nothing sits underneath.
Deletions ask for a reason and are kept in the record, like every other removal in the platform.
5. Who can change what
Reading properties needs platformconfig.property.read; creating and editing need
platformconfig.property.write; removing needs platformconfig.property.delete. A facility
administrator with write permission can create a facility-scoped row; changing the platform row
affects every tenant, so that permission is normally held only by platform operators.
Whichever scope you choose, the system fills in which tenant and which facility from your signed-in session — you cannot set a value for a facility you do not have access to, even by editing the request.
6. Settings in use today
| Name | What it controls |
|---|---|
billing.default_currency | The ISO currency code new charge-master prices default to. See the billing guide. |
The list grows as features gain settings; this table names the ones an administrator is expected to set deliberately.