Feature flags

Not every part of Cooriroo is on for every tenant. Capabilities are gated by feature flags — small named switches the product checks before it shows a screen or accepts a request. Most of them are decided entirely by your plan. Three of them are not, and those three are the reason this page exists: they need two switches to agree before anything changes.

For a small set of features, being allowed to use something and having chosen to use it are separate facts, held in separate places by separate people. The platform team decides whether your tenant may use a capability. You decide whether your tenant does. The feature is live only when both are true — the two levels are combined with AND, never with OR.

The split is deliberate. Without it, buying a capability would silently change how everyone’s screens behave the moment a contract was signed, and turning it off again would mean asking someone outside your company to make the change.

Exactly three features work this way. Every other flag in the product is a single gate — the entitlement alone decides it.

• Delivery pools — the pooled-destination subsystem, opted into under Operations once your plan includes it.
• Optional vehicles — whether a trip can be assigned or started without a vehicle. This one is inverted, and worth reading twice: a vehicle is required by default. The entitlement grants the ability to relax that rule, and the Operations toggle is where you relax it. Without the entitlement the control is locked on, not off.
• Destination default tasks — automatically importing a destination’s default tasks onto a stop that links to it. Entitled but not opted in means stops stay empty, which looks exactly like the import failing.

The entitlement half of the gate is itself resolved from several layers. They are checked in a fixed order and the first that applies wins, so knowing the order tells you which conversation to have when a value surprises you:

1. Kill switch — a global emergency stop for one feature across every tenant. It beats everything below it, including a plan that clearly includes the feature.
2. Tenant exception — an add-on, promotion, trial or manual grant issued to your tenant alone. It beats your plan, and a time-boxed one lapses on its own.
3. Plan — the version of the plan your tenant resolves against. This is where most answers come from.
4. Built-in default — what the product ships with when nothing above applies. For nearly every gated capability that default is off.
5. Fallback — if the value genuinely cannot be read, each feature has a declared behaviour. Most gated capabilities deny; usage metering deliberately allows, so an infrastructure problem never blocks paying work.

Two populations of flags share that resolution order, and telling them apart tells you who to ask.

• Commercial entitlements are plan values: the numeric caps behind Plan & Usage, the AI assistant switch, the route-optimisation level. They are derived from your plan version rather than stored separately, so changing a plan’s limits changes them and nothing else has to be kept in step.
• Operational flags are engineering switches: delivery pools, live driver presence, geocoding auto-fill, import history, the MCP endpoint, campaign chatbot, custom-field expansion, and the external-integrations engine. They exist so a capability can be rolled out or stopped independently of any plan.

Flags are matched on stable keys, never on plan names, which is why a tenant on a plan called Enterprise and a tenant on a bespoke arrangement can resolve to exactly the same set of capabilities.