Automation

BigLedger has no workflow engine, and this page is the honest answer to what it has instead: four separate mechanisms, none of which is a visual designer or a rule language, and each of which is worth knowing about before you build an integration around any of them.

The four mechanisms

Everything else — branching, retries, escalation, orchestration across steps — is yours to build.

React to a change: webhooks

Register a subscription (a URL, a topic, one optional header) and BigLedger POSTs the changed record to you. Webhooks documents the whole mechanism, including four absences that change how you must build:

• no signature — the payload is not signed; the only credential is a static header you chose;
• no retry — one attempt, ever, with no dead-letter queue and no replay;
• no alerting — the notification fields on a subscription are loaded and never looked at again; no mail or SMS sender exists in the delivery path;
• no readable delivery log — attempts are recorded, but the endpoint that lists them always returns an empty list, whatever was delivered.

The consequence is the single most important design rule on this page: treat a webhook as a hint that something changed, never as a delivery guarantee. Re-read the record through the Data API before you act on it, and pair every subscription with a periodic updated_date_from reconciliation pull. The webhook makes your integration fast; the pull is what makes it correct.

Run something on a schedule: the tenant cron table

Each tenant has a cron table. A row pairs the queue code of a background job processor with a UNIX cron expression and an optional JSON payload of properties for that job. On each platform tick, BigLedger reads the tenant’s active rows, works out which are due, and puts the matching job on the tenant queue.

The Scheduler applet is the screen for this and documents the behaviour in full. Over the API:

These need API_TNT_DM_SCH_CRONTAB_READ, _CREATE, _UPDATE or _DELETE, or the broader _OWNER / _ADMIN grants. There is no documented etl-ep path for any of them, so a scheduled job is set up by a signed-in user rather than as part of a server-to-server integration.

A schedule row carries:

What you can schedule: job processors

Everything BigLedger does in the background is a job processor — a named unit of work with a queue code, a description and a properties class. There are 597 of them registered in the platform. A processor has to be registered and enabled for your tenant before it can be selected; that is a platform-side step, visible in the Developer SysAdmin applet.

A few that show what the mechanism is for:

That last one is not a report scheduler, and scheduling it does nothing. Reports are defined in the BI report surface (/core2/tnt/dm/bi-reports/…, backoffice-ep throughout; there is no documented etl-ep path into it). The processor acts only when the request that queues it names a specific query run or query event, which is what the Dynamic Report screens do when you create one. A cron row with that code, as the Scheduler creates it, names neither, so each time the clock fires it queues a job that finishes without doing anything.

Scheduled reporting does not work today. A Query Event’s future occurrences are stored in a waiting list that nothing reads, so a recurring event produces the runs that were already due when you saved it, and then nothing more. BigLedger intends scheduled reports to work. Until they do, run the schedule in your own system and pull the figures through the Data API on your own clock. See Dynamic Report › Scheduled runs. There is no “generate report of type X” API endpoint.

Chained jobs, and why you cannot define one

BigLedger can run a second job when a first one finishes: a platform-level applet trigger template links a publisher job processor to a subscriber job processor, and a tenant enables that link by holding a matching trigger-configuration row. The e-invoice pipeline is built this way.

The half that decides which job follows which lives in the platform registry, not in the tenant. A tenant can enable or disable a link that already exists; it cannot create one, and neither can you. If you need work chained, chain it in your own system.

The largest chain in the product starts when somebody finalises a document

Finalising a generic document — a sales invoice, a cash bill, a purchase order, a credit note — is not a save. It is its own endpoint, PUT /core2/tnt/dm/erp/gen-doc/{docType}/update-posting-status/{guid} with posting_status: FINAL in the body, and the last thing it does before returning is put one row on the tenant queue for the Generic Document Primary Processor. That processor exists to fan out: it reads the subscriber links for its own queue code and queues one job for each.

Dozens of processors subscribe to it in the platform registry — the journal posting, the inventory transaction line, the cashbook line, two e-invoice matching queues, the membership point update, four coupon processors, finance charges, budget register lines, historical aging for a back-dated document, intercompany, the open-queue (knock-off) processor, bundle and make-to-order unwrapping, sales commission, non-stock trade-in, and several integration-specific ones. None of that is on the screen, and the count is a property of the platform rather than of your tenant.

Three filters decide which of them actually run for one document, in this order:

1. Your tenant’s subscription. Only links whose applet trigger template has an ACTIVE bl_applet_trigger_config_hdr row in your database are returned at all. This is the switch that matters: the same button in two different databases does different amounts of work, because the subscription list behind it differs. The stock chain is one template covering all three of its levels, so it is on or off as a unit.
2. Your company’s override list. bl_fi_mst_comp.posting_final_json may carry includeJobProcessorCode and excludeJobProcessorCode arrays; an excluded code is skipped, and if the include list is non-empty everything not on it is skipped. It is an override on top of the subscription, not the thing that enables anything, and it stays unset until somebody sets it — so unless your company has one, the subscription is the whole answer.
3. The document type on the link. A link may carry serverDocTypes and clientDocTypes constraints; the job is queued only if this document matches. Most links carry none and therefore match every document type.

The chain is deeper than one hop

A subscriber may itself be a publisher. Stock is three levels below the button:

Finalise  →  BLG_ERP_GENERIC_DOCUMENT_PRIMARY_PROCESSOR
          →  INVENTORY_TRANSACTION_LINE_PROCESSOR                     (writes the stock ledger line)
          →  INVENTORY_TXN_LINE_TO_CURRENT_STOCK_BALANCE_PROCESSOR    (balances, moving average, write-back)
          →  INVENTORY_FIFO_LIFO_COSTING_PROCESSOR                    (FIFO baskets, FIFO write-back)

Each level re-runs the same lookup for its own queue code, so the depth is data, not code.

What the queue does with a job that fails

The queue row is deleted before the handler runs — DELETE … RETURNING is how a worker claims it. So a handler that throws does not leave a row to retry: the failure is written to app_scheduler_std_error with the event code, the properties (which carry the document GUID) and the message, and nothing re-drives it.

The safety net covers the other failure: a row that was inserted and never attempted. The Main Tenant Processor’s tick reads up to ten distinct event codes from app_scheduler_queue and calls the job endpoint once for each, and that endpoint pulls a single event per call. That is what makes asynchronous posting safe against a restart — and it is also why a tenant producing work faster than one job per code per tick accumulates a visible backlog in that table.

Approvals

What the engine does expose over the API is the approval record for a document, so an integration can read where a purchase order stands and react to it:

The behaviour behind them — levels, quorum, the Min Approval Amount rule, the two notification e-mails, and the move to FINAL on the first approval — is described in Document Approvals. Anything beyond that (reminders, escalation, routing by supplier or category, a mobile approval app) has to be built in your own system.

The pattern that works

Automation that holds up on this platform looks the same every time:

1. Subscribe to the topics you care about, one URL per subscription.
2. Re-read the record through the Data API when a webhook arrives. Do not trust the body.
3. Decide and act in your own system. Your conditions, your retries, your audit trail.
4. Write back through the etl-ep endpoints in the API Reference.
5. Reconcile on a schedule with an updated_date_from pull, because step 1 drops events silently.
6. Schedule BigLedger’s own jobs for the work that has to happen inside BigLedger — recurring documents, replenishment runs, e-invoice sweeps. Not report runs: those do not run on a schedule today (see above).

Start at Integration: Getting Started, which takes you from no credential to moving real data.

What is not there

Stated plainly, because it changes what is worth designing:

Related documentation