Document database

A global, schema-less store of collections of JSON documents, managed in the UI and readable/writable from process steps.

Unlike process context (per-run) or templates (workflow definitions), this is durable cross-run application data — closer to a small MongoDB than to a spreadsheet integration.

Model

  • Collection — keyed string (vendors, deal_notes). Optional display name.
  • Document — JSON object with a string _id. Stored with system timestamps; user fields live in a applications/main/data envelope internally and are flattened ({ _id, …fields }) in the API, UI, and step results.

Scope is global to the deployment (same as templates): all Auth0 orgs on a given MONGO_URL share the same collections. Gate access with database:read / database:write.

UI

Sidebar Database (requires database:read):

  • /database — list / create / delete collections
  • /database/[key] — list / create / edit / delete documents (JSON editor)

API

RouteMethods
/api/database/collectionsGET, POST
/api/database/collections/[key]GET, PATCH, DELETE
/api/database/collections/[key]/documentsGET (?filter= JSON), POST
/api/database/collections/[key]/documents/[id]GET, PUT, DELETE

See permissions.

Process steps

  • database_read — collection key + optional filter expression → context.<stepKey> = { documents, count }
  • database_write — collection key + mode (insert | update | upsert) + document expression; optional id and/or filter for update/upsert

Both fail the run on error. Details: step types.

Storage

Implemented as IDocumentDbService (separate from IStorageService):

DriverWhen
Mongo (doc_collections, doc_documents)MONGO_URL set
Files under .process-platform/local / no Mongo
MemoryVitest / STORAGE_DRIVER=memory

Filter matching is equality-only (including dotted paths into document fields, and _id). No $gt / $in operators in v1.