Integrations
One connector contract: test the connection, fetch, map the fields. Directory and ERP connectors are live today, and reader and device-management connectors use the same shape.
The same shape, whatever is on the other end.
A directory, an ERP, a card reader controller, and a device-management platform are very different systems that pose the same three questions.
Every connector implements the same contract: prove the connection works, fetch records, and map remote fields onto local ones. That uniformity is why adding a connector is a small piece of work rather than a project, and why the operational surface for all of them is one screen.
Each connector runs in mock mode or live mode. Mock mode uses representative demo data so you can see the mapping, the volumes, and the failure messages before any production credential is entered. It is the difference between evaluating a connector and gambling on one.
Credentials resolve from the environment or a secret store as well as from the database, so a hardened deployment never has to keep a live secret in a row somebody can select. Every sync writes provenance, recording which connector supplied which field and when.
- Test
- Validates credentials and reachability, changes nothing
- Fetch
- Pulls records with paging and incremental cursors
- Field map
- Remote field to local field, editable per tenant
- Modes
- Mock with demo data, or live
- Secrets
- Environment or secret store, with a database fallback
- Scheduling
- On demand or on an interval
- Provenance
- Source and timestamp recorded per record
- Conflict handling
- Directory is authoritative for identity
What connects, and what it brings in.
Directory, ERP, portal, and device connectors all implement the same three operations, which is why the operational surface for every one of them is a single screen.
| Connector | Brings in | Keyed on |
|---|---|---|
| Microsoft Entra ID | Users, groups, memberships, account state | Directory object id |
| LDAP and Active Directory | Users, groups, memberships, organisational units | Distinguished name |
| SAP S/4HANA | Cost centres, employee records, purchasing context | Personnel number |
| Dynamics 365 Business Central | Vendors, purchase orders, fixed assets | Vendor and asset number |
| Reader controllers | Portal inventory, access list push, health | Portal identifier |
| Device management | Device inventory, enrollment state, compliance | Serial number |
Wiring a directory in.
The path most customers walk first, because it is the prerequisite for everything else.
Start in mock mode
See the record shape, the field mapping, and the group structure against demo data. No production credentials involved.
Map the fields that matter
Confirm which remote attribute is the stable identity, which is the display name, and which groups should become access audiences.
Switch to live and dry run
Point at the real endpoint and run a fetch. You see counts, conflicts, and the records that would change before anything is written.
Schedule it and watch provenance
Once it runs on an interval, every synchronised record carries its source. A surprising value is traceable to the connector that supplied it.
Boundaries we hold to.
Your directory stays authoritative
Baselivery consumes identity state and never becomes the identity provider.
No hard dependency
Nothing here requires another product from us to be present.
Optional event hooks
Where a customer runs our operational suite too, joiner events can raise equipment requests. It is optional.
Audited
Every sync run is an event with counts, duration, and outcome.
Failure is visible
A broken connector surfaces on the dashboard rather than failing quietly overnight.
Same contract for readers
Portal controllers are connectors, which is why they are operationally boring.
Related
Bring the door onto the same epoch as the laptop.
We will walk you through a live portal, a compiled policy pack, and a revocation that closes the turnstile and locks the screen while you watch.