Connect
Don’t replace every system. Connect the operation between them.
Your organization already depends on systems that serve important purposes. Phibian is designed to connect around them — the goal isn’t another closed ecosystem, it’s a better operational layer across the systems you already rely on.
The architecture principle
The system of record is a connector, not a cage.
Most operational software eventually asks an organization to move its records. Phibian is built on the opposite assumption: your records should stay where they belong, and the operational layer should be able to work across them.
That is an architectural commitment, not a marketing position. Connectors are a defined abstraction with their own boundary: nothing outside a connector may depend on a vendor’s field names or response shapes, so adding or replacing one never reaches into the operational core.
It also means an organization can run Phibian with no integrations at all. A tenant can be populated and operated entirely by hand — connectors reduce double entry, they are not a precondition for the product working.
Categories
Where Phibian connects — and how far along each is.
Status is stated per category against the product repository.
Connector framework
The abstraction every connector is built on: declared credential schemas, per-tenant credential storage, explicit lifecycle states and honest degradation.
Systems of record / EHR
Phibian treats the system of record as a connector, not as the centre of the architecture. Identities map onto the Phibian directory rather than creating a parallel one.
Payroll
Approved timesheets are snapshotted and exportable today. Direct connectors are designed as a push of approved hours into your payroll system — Phibian never becomes the money-of-record.
Identity
Authentication runs through your organization’s identity provider. Phibian does not hold a parallel password for your staff.
Communication
In-app operational channels ship today. Outbound SMS delivery is deliberately switched off until per-tenant credential isolation is complete.
Operational systems & APIs
Anything that needs to contribute to, or consume from, the operational record — through the same connector model, with the same tenant boundary and audit trail.
How connectors behave
An integration that lies is worse than no integration.
These rules exist because a silently failing sync is indistinguishable from an operation that has gone quiet — and organizations make real decisions on the difference.
Credentials are yours and write-only
Integration credentials go to a managed secret store; the database holds only a reference. No API response ever returns a stored credential, and no credential is shared between organizations.
A connected credential is not proof it works
Storing a credential never sets an integration to “connected”. It has to pass a test, and it can only re-enter a healthy state by passing one again.
Failure states stay distinguishable
Invalid credentials, a failing upstream API, a collapsed dataset and a deliberately disabled integration are different states — because an administrator needs to tell them apart.
Degraded data is labelled, never silently shown
Data from a degraded integration is never displayed as though it were healthy, and a materially collapsed dataset raises an anomaly rather than overwriting trusted records.
Working with us
Tell us which systems you actually run.
Connector priority is driven by real customer operations rather than by a logo wall. If a specific system is critical to your operation, that is a useful conversation to have early — including if the honest answer is that we are not ready for it yet.