Where Orchestration Builder keeps your work

App Hub holds only what you have saved with Save to App Hub, and a later save from another session replaces it without warning. Every Save to App Hub does create a build, and the app's Activity tab on the Workday Developer Site lets you view or download the source of each build, so a vanished orchestration can usually be recovered from there.

Workday's steps for building an orchestration end with the same instruction every time: when you've made changes, click Save to App Hub to upload them. Validate checks the code but does not store it. Save to App Hub validates, saves the app's code to App Hub and writes a build log, and App Hub then compiles that source into a build. Anything you did on the canvas after the last successful save exists only in the open tab.

Why saving does not give you a version history

App Hub has versions and it has builds, and they are not the same thing. A version is what you promote. Workday's documentation on updating apps says that when you change the source of a version you haven't promoted beyond Development, App Hub updates that existing version with your changes and does not create a new one. Each save produces a new build of the same version.

So "version 2" on the morning you started and "version 2" after twenty saves are the same version with different source. If you are looking for an earlier state of an orchestration, look at builds, not versions. A new version number appears once the current one has been promoted: Workday's example has version 1 live in Production and the next source change arriving on Development as version 2. Each promotion level then replaces the version that held it before, as the integration app lifecycle page describes.

The usual ways an orchestration disappears

Two sessions saved the same app. App Builder has a Merge Conflict Manager that stops a save with a Cannot Save to App Hub message when App Hub holds newer changes. Workday states that it covers Extend components only: changes made to orchestrations in App Hub do not trigger a merge conflict notification. Two people, or one person with two tabs, can therefore save orchestration changes over each other with no warning, and the later save wins.

The edits were never saved. If the newest build on the Activity tab is older than the work you remember, that work never reached App Hub, and App Hub has no copy of it. Validating does not count as saving.

Local Disk Sync was on, and then it wasn't. In a local folder session, changes are written automatically to the folder on your machine, not to App Hub. Workday's steps say you must choose Open from Local Folder every time you want to keep working that way, and that you update App Hub only with Save to App Hub or the WDCLI upload command. Open the same app the normal way and you see the App Hub copy, which may be days behind your local folder. When editing from a local folder, App Builder defers to the local disk's latest changes, so the reverse also applies: an old local folder can overwrite newer App Hub work the moment you save.

The app was deleted from App Hub. The App Hub page says that once an app is deleted from App Hub you can no longer access it on any Development tenant it was deployed to. Check the Console's Apps list before anything else if the whole app, not just one orchestration, is missing.

How to recover an orchestration from an earlier build

  1. On the Workday Developer Site, open the app from the Apps section of the Console and go to the Activity tab. Builds are listed newest first, with version number, promotion level, creation time and build details, in your local time zone.
  2. Find the last build that should contain the missing work. From that build's menu, choose View Source to open that build's source in App Builder and confirm the orchestration is there.
  3. Choose Download Source to get a .zip of that build's source. In Workday's sample apps, orchestrations sit in the orchestration/ folder as .orchestration and .suborchestration files.
  4. Decide how much to restore. If the whole app should go back to that state, overwrite your app with the downloaded source, for example by extracting it and saving it from a local folder session, or with wdcli app upload. If you only need one orchestration back and the rest of the app has moved on, create a separate app with Upload a Zip File (one of the options when you create an integration app), then in the real app use Import Existing Orchestrations to pull just that orchestration across. Imported orchestrations bring their suborchestrations with them and become independent copies.
  5. Validate, then Save to App Hub.

The Activity tab also offers Compare Changes With Previous Version and Compare Changes With Previous Build, but Workday notes that both are available only for Extend applications and Extend components, not for orchestrations or integration apps. To see what changed in an orchestration between two builds, download both and diff the .orchestration files yourself.

Import has two side effects worth checking after step 4. Connectors used by the imported orchestration are added to the app's Connectors tab, but connected accounts are not imported, so you must set up the Default and Production accounts again. Agent actions need registering again, and if a name clashes Orchestrate appends a number, which can push the action name past the 30-character limit and fail the build.

How to prove the recovery worked

Open the app's Activity tab and confirm a new build at the time of your save with a successful status, then open that build's View Source and find the orchestration with the steps you restored. Reopen Orchestration Builder in a fresh tab, not the one you saved from, and check the canvas. If the orchestration is deployed, run it once on the Development tenant and read the run in its logs before anyone relies on it.

How to stop it happening again

These are recommended habits rather than Workday rules, and each one closes a gap described above.

Keep the source in Git. Local Disk Sync writes every change you make in Orchestration Builder to a folder, and Workday describes it as the way to bring Builder work into a version control system such as Git. Commit before each Save to App Hub and you have the history App Hub's in-place versions do not give you. It needs a Chrome or Chromium-based browser, and for integration apps it requires the Extend SKU, so an Orchestrate-only subscription has to rely on the download habit below instead. The guide to Workday Extend version control with GitHub covers the repository layout.

Agree who saves orchestrations in a shared app. Since nothing warns about overwritten orchestration changes, one owner per orchestration at a time is the simplest protection.

Download source before risky edits. The Console's app menu has Download Source, and the WDCLI has wdcli app download <app> --latest-version; wdcli app versions and wdcli app builds list what App Hub holds. The WDCLI guide covers setting it up.

Save to App Hub in small steps. Each save is a build you can return to from the Activity tab, so frequent saves make that tab a usable history.

If a save itself fails rather than vanishing, the problem is the build, not the storage; Workday Extend deploy errors covers reading the build log.

Sources checked