Workflow Publishing, Scheduling, and Execution
Publishing moves a workflow from Designer to the Gallery. The Save to Gallery flow uploads the workflow, resolves its dependencies (macros, data files, spatial objects), and stores it in the persisted workflow directory with metadata in MongoDB. Apps are workflows published as interactive interfaces; they expose interface tools as questions and can be chained (one app calls another). Versioning lets you publish updates while retaining prior versions.
Scheduling is driven by the Controller. A schedule specifies a workflow, a frequency (including cron-style expressions), a Run As user, and notification settings. When the trigger fires, the Controller queues the job and a Worker picks it up. Priority and worker tags influence which worker runs a job-tags let you route workloads to specific workers (for example, workers with particular drivers or memory). Chained apps and iterative macros affect runtime behavior and must be tested.
Traps: assuming a schedule runs on the machine where it was created (it runs on the Controller/Worker infrastructure); forgetting that credentials stored in the workflow or configured in the schedule must be valid on the worker; expecting a scheduled workflow to see a user's local files (it cannot-use network paths or data connections); and ignoring that changing a workflow's dependencies after publishing can break scheduled runs.
Worked example: A nightly schedule fails only on one worker. The workflow reads a file from a mapped drive. Mapped drives are per-user and often absent under the service account. Replace the mapped drive with a UNC path and grant the service account access-this is the classic scheduling failure.
Rule of thumb: a scheduled workflow must be self-sufficient-it can only rely on resources reachable by the service account on the executing worker, not on the author's desktop.