Tenancy and Custom Code
Two older custom-PHP paths are refused automatically whenever tenancy is enabled. This is deliberate and it is worth understanding rather than working around.
Where to find it
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
Architect Panel → Automation:
- Extensions — the supported way to run custom logic
- Workflow Builder — rules, which cover most cases
What is refused
- The rule action that runs a PHP script.
- The custom-PHP field type.
Both execute code written by an architect, with no sandbox, in the platform’s own process.
Why tenancy changes the answer
On a single-organisation installation, an architect writing unsandboxed PHP is running code on their own system — a reasonable thing to allow.
With tenancy on, that same code runs in a process shared with every other tenant on the installation. An architect in one customer’s tenant would be executing unreviewed code alongside everybody else’s data. That is not a permission anybody can safely grant.
It is refused automatically
Not left as a setting somebody might forget. The check happens because tenancy is on, which is the right shape for a control of this kind — a security boundary that depends on somebody remembering is not a boundary.
What to use instead
- Rules cover most of what these paths were used for — conditions, actions, notifications, field updates.
- Extensions cover the rest. They run out of process, under a timeout, a memory limit and an outbound allowlist, with a circuit breaker.
Extensions exist precisely because custom logic is legitimate and unsandboxed execution is not.
There is an override, and it is narrow
A configuration setting allows the legacy paths, and it exists for one situation: a self-hosted installation that runs tenancy for its own internal reasons and already depends on those paths.
If you serve external customers, this is not for you. Setting it means an architect in one tenant can run arbitrary code affecting all of them.
Migrating existing usage
If you are turning tenancy on and have existing custom PHP, find it first. A rule that stops working when tenancy is enabled is a bad way to discover a dependency.
Rewrite each as a rule or an extension before the switch, not after.
Worked example
An installation enabling tenancy found four rules using the PHP script action. Three were reimplemented as ordinary rule actions; the fourth, which called an external service, became an extension with the service’s host on its allowlist. Tenancy was enabled afterwards, with nothing broken.
Recommendations
- Find existing custom PHP before enabling tenancy.
- Rules first, extensions for the rest.
- Do not set the override if you serve external customers.
- Treat the refusal as correct, not as an obstacle.