The heartbeat
One serverless task runs on a clock and drives everything: it starts scheduled extracts, registers new files on the inbox, batches staged rows, polls imports in flight, re-runs the entitlement sync, finalizes runs that overran their timeout, and purges once a day. Every piece of work it starts runs in its own one-shot task, so nothing waits on a browser and a page refresh never loses a running job.
The heartbeat is suspended when the app is installed and resumed from Admin once the connection test passes. Suspend it to stop everything at once, during a Workday maintenance window for instance; resume it and the schedule picks up where it left off.
Compute and leftover tasks
Every worker runs in a one-shot task that drops itself when it finishes; the heartbeat drops the tasks of finalized runs and sweeps anything older than two days. After a quiet period only the heartbeat should remain. The tasks are serverless and cost almost nothing while idle.
The warehouse cost is the pages themselves: Streamlit in Snowflake keeps the session warehouse running while a browser tab is open. Close the tab when done and give that warehouse a short auto-suspend.
A run is stuck
The next heartbeat marks a run that has exceeded the in-flight timeout under Admin as failed and finalizes it; the records of a stuck submit stay pending and the next Submit sends them. If a Snowflake task itself is hung, find the statement in query history and cancel it there. The app never cancels statements on its own.
A dropped file did not load
History lists every file the inbox saw with its status. Rejected carries the reason: a bad folder, an unknown business object, no root rows, a missing key column. Waiting is a child file whose root has not arrived. The result file beside the drop says the same. To retry, drop the file again with new content; identical content is skipped as a duplicate. Scan inbox now on Admin registers files without waiting for the heartbeat.
A batch is importing
A batch over the threshold under Admin, or one whose business object's load method says Workday import, goes through the writer's bulk import operation in chunks and shows as Workday is importing in History. The heartbeat polls Workday on the interval under Admin, so nothing moves while the heartbeat is suspended. After the import timeout an import still running is marked failed and its records keep the process they went in, so the result can be read from Workday's side.
Workday names a refused record by its position in the call; accepted records are read back by their source key, which the submit writes into the record's own ID by default. If every record of a process fails with an invalid user name or password, the secret has no basic entry or the tenant refuses that user; see Workday setup and credentials.
Sending faster
A batch sends one record per call, several at once in waves, each on its own Workday connection. The parallelism under Admin is the most a batch will send at once; every business object starts with tuning automatic, so the wave size follows the tuner: down one level after a transport failure, up one level after three clean full waves, with a wait that doubles each time the same level fails again. Start at a modest ceiling, watch the tenant's response times on Overview, and raise it while they hold. Source order is only kept at a parallelism of one.
The accepted records of a wave are read back from Workday in one call rather than one each. For an object that reaches hundreds of thousands of records, the submit's result lookup can say "verify": "later" to skip that read-back and leave confirmation to the next extract.
Extracts are tuned the same way for max workers per batch of pages and page size per run. Every decision is logged, the Operation page lists the changes and the levels the next run starts at, and Start over forgets what was learned.
A new Workday release
Workday publishes a new web service version twice a year. The app's catalog carries each operation's bundled versions, and the Operation page offers them beside the one in use with the differences shown. Switching an operation to a new version brings its tables up to date: new columns are added, nothing is dropped or retyped, and the views are recreated. Run a small ad hoc window afterwards to confirm.
Upgrades of the app
Snowflake upgrades the app in place when a new version is released on the listing. Tables, settings, rules, entitlements, highwater marks and batches survive; migrations are applied by the setup script and are safe to re-run. The heartbeat keeps its state. Read the release notes on the listing for anything that needs a hand.
Support
Use the support contact on the listing. When you write, say which business object and which batch or run, from History; the XML tab on the batch has the exact request and answer, redacted, which is usually all that is needed. Nothing in the app leaves your account, so support never sees your data unless you choose to send it.