Part 11 of 13 · Shipping It

From source code to an approved workflow component

Source control records what changed; the build pipeline identifies the resulting artifact; activation policy decides which workspace may run it.

Read the article on Substack ↗ (opens in a new tab)

Summary

An improved invoice extractor passes evaluation, but three workflows use the current one: the exception workflow wants the fix now, a high-volume straight-through workflow is in a quiet-period freeze, and a pilot’s owner has never heard of the change. If publishing silently replaced the old version everywhere, the freeze would break and the pilot owner would be debugging an unexplained behaviour change — so publication and use must be separate decisions.

The first adjustment for anyone coming from application delivery is what counts as software: workflows, agents, code tasks, integrations, human tasks and review interfaces are all versioned assets with operational effects, so changing a prompt or a review screen is a production change. The arrangement that treats them this way is called the Open Code Architecture, with the name clarified — it refers to open engineering access and controls, not to the platform being open source.

Components can be authored in the Workflow Builder or off-platform in an ordinary editor with a skills file describing the component’s method, then committed to Git, reviewed by pull request, merged, built and promoted through development, staging and production by a CI pipeline that records exactly which revision runs where. Publication registers a version in the organization’s internal marketplace alongside its predecessors without replacing them, and verified organizations can publish into a public marketplace from which others clone components into their own governance.

Activation is the step that answers the opening problem: a marketplace component is available but unusable until someone with authority over a group or workspace activates it there, which lets each of the three teams decide independently. Components are referenced rather than copied, so the platform can answer which workflows run which version and which cases were processed by which — and rollback is re-activating a previous version, with in-flight case behaviour governed by workflow settings that are worth understanding before relying on it. The cost is release overhead plus the real work of reconciling builder edits with source-control changes when both paths are in use.

All thirteen parts →