Background work that can't cross tenant lines.
Typed events, scheduled connectors, and queue processors that run under tenant-scoped sessions. Integration without integration risk.
- ·Background jobs run under a tenant-scoped session, so the nightly job cannot read across customers the way a service account usually can.
- ·Connectors and event subscriptions are registered as data, so standing up a new feed does not require a platform release.
- ·Failures retry per message with backoff and surface as notifications and logs, instead of a feed going quiet for a week.
Background jobs are where security models quietly die.
Interactive users go through the app's security. Then a nightly job connects as a service account with database-wide access, and the careful permission model means nothing between midnight and six.
Integrations also tend to be invisible: a feed fails silently, one poison message kills a batch, and the first anyone hears about it is a business user asking where yesterday's data went.
The mechanisms, not the adjectives.
Typed events, governed keys
A typed event log is the backbone. Event types are registered artifacts with governed, segment-composed keys, designed for very large volumes. Connectors and application code emit events; queues subscribe to them declaratively.
Integration becomes observable data instead of tribal knowledge about which job writes what.
Connectors on a schedule
A connector service runs pull-and-push integrations on CRON schedules. SFTP ships today; connectors are pluggable .NET types registered as data, so standing up a new feed doesn't require a platform release. A broader connector catalog is on the roadmap.
Partners and ops can stand up a feed without a deploy, and every run is logged.
Tenant-scoped processors
Queue processors dispatch batches under an impersonated, tenant-scoped session. Background work goes through the same data path as interactive users: same foreign-key-derived scoping, same permission keys, same audit.
The nightly job physically can't read across tenants. The security model doesn't have office hours.
Failure handling built in
Per-message retry after batch failures, retry delays with error backoff, scheduled cleanup, and consolidated system logs with export. Failures surface as notifications, not as silence.
One bad message can't poison a batch, and nobody discovers a dead feed a week later.
A partner feed, end to end.
- 1
Register an SFTP connector with its schedule and credentials. It's a row of configuration pointing at a .NET type, not a deployment.
- 2
The connector pulls the file and emits a typed event per record into the event log.
- 3
A queue subscribed to that event type picks up the batch and dispatches it to a processor.
- 4
The processor runs under a tenant-scoped session. Its writes are scoped, validated, and audited like any user's.
- 5
Three records fail validation. They retry individually with backoff; the other records commit, and the failures show up in the system logs and notifications.
The AI angle.
Gartner expects over 40 percent of agentic AI projects to be canceled, largely over risk controls. An agent that acts through this pipeline emits events, is processed under a scoped session, and leaves an audit trail. That's what a risk-controlled agent architecture looks like in practice.
Keep going.
AI done right
MCP-native access, prompt-authored rules, and a security engine every AI agent inherits.
Go deeper →Data & instant API
Register a table and it is secured, audited, and queryable. No ORM, no per-table code.
Go deeper →Operations
The platform ships with its own ops console, real-time notifications, and full change history.
Go deeper →See it on your schema, not ours.
A fixed-price assessment gets this running over your actual data.