Picking up a stalled recipe (when embedded beats correct)

At the studio I'm contracting with, Epic Games, the publishing-operations team manages the work that turns new Fortnite in-game offers (cosmetic packs, V-Bucks packs, weapon bundles) into shipped products across downstream teams (localization, art, engineering, catalog, test). Each offer needs a cascade of Jira tickets, one per downstream team's piece of the work. Before any automation, that cascade got built by hand: someone watched a Slack channel for new offers, identified when one had enough information to act on, and manually created the Jira tickets.

That manual process eventually got an Airtable catalog upstream. Then an internal team at the studio built a Workato recipe to translate the catalog records into the Jira ticket cascade. The recipe didn't work. The publishing-operations team was blocked.

I sit with that team. I don't work for the team that built the recipe. But the back-and-forth between "we need this fixed" and "we're triaging across all the Workato work we own" was producing more delay than progress. The team that owns Workato asked me to take it over.

So I did. This is the recipe that came out of that.

A Workato recipe that watches the Airtable catalog for new and updated offer records, then creates the cascade of Jira tickets for downstream teams.

The shape:

• Trigger: new or updated offer records in Airtable.
• Error-monitored wrapper: all downstream work runs inside an error-monitored block. Any failure routes to a terminal "do not retry" step instead of auto-retrying, because a half-completed ticket cascade can't safely re-run without producing duplicates.
• Identity lookup: resolves Assignee and Reporter against Jira users, branched on whether the source record has an Email field present.
• Offer-type branching: three top-level paths based on the offer record's type, producing different ticket trees.
• Per-branch ticket cascades: each branch creates a sequence of Jira tickets covering the downstream work for that offer type. Fulfillment, metadata translation, display assets, test trackers, and so on.
• Airtable writeback: the source record gets updated with the created Jira ticket references so the team can see what was routed.

The branching logic encodes business rules I didn't design. They came from the team's existing routing practice from the manual era. The recipe's job was to translate that practice into reliable automation, not to optimize it.

This is the most FDE-shaped decision in any of my projects, and the cleanest example of why embedded engineering is its own thing.

The "correct" answer on ownership was to keep waiting for the Workato team to fix their own recipe. They own the platform. Recipes are their lane. Reaching across team boundaries to take over their work breaks the normal ownership pattern.

The faster answer was for me to take it over. I sit with the team using the recipe. I could:

• Iterate on the recipe in the same Slack channel as the people running into the bugs, without ticket-based feedback loops.
• Test against real offers and watch failures surface in real time, instead of waiting for the next consumer to hit the same bug.
• Ship a fix in a morning and verify it the same afternoon, instead of queueing behind a cross-team backlog.

Cross-team handoffs are expensive. Embedded engineers cut the handoff cost toward zero. That's the load-bearing reason the FDE shape exists as a role at all, and this recipe is the cleanest example of it in my work.

The decision worth keeping: when an external team's stalled deliverable is blocking your team, take it over if you're closer to the problem than they are. Not always the right call. There are cases where reinforcing ownership boundaries matters more than unblocking. In this case the calculus was clear, and the team that owned Workato explicitly asked for the help.

I don't know why the recipe has three branches. I don't know which specific downstream teams pick up which specific tickets. I didn't need to.

The publishing-operations team already had the routing logic in their heads from the manual era. They knew that one offer type needs one tree of tickets, another needs a different tree, a third needs extra tickets for gift-box packaging work. My job was to translate that existing practice into automation, not to question it or optimize it.

Optimizing without the domain knowledge would have broken things that were already working. Encoding what the team already knew was the right move, even though it left some "why does this branch exist" questions unanswered on my side.

This is part of the FDE shape too. The customer holds the domain knowledge. The embedded engineer holds the engineering judgment. The translation between them is the whole job.

Workato is a low-code platform. The recipe is built in a visual editor with declarative steps, conditional branches, and connector boxes. No JavaScript, no scripts.

That doesn't make the engineering judgment any less real. The work in this recipe is the design of the branching, the error handling, the write ordering, the conditional lookups, the decision to route failures to "do not retry" instead of auto-retry. The thing that's missing relative to code-based work is the typing-in-an-editor part, not the engineering-judgment part.

The proof is the production record. The recipe has run 77 times in production since it shipped in March. Zero failures. That's real reliability, on a real production workflow that downstream teams depend on every time an offer ships.

The "is low-code real engineering" question gets asked sometimes. The answer is in the production record, not in whether the work involves a text editor.

In production since March. 77 successful runs, 0 failures, as of the latest check. Stable. No active development. The recipe encodes the current routing logic correctly, and future work would only come from new offer types or downstream-team changes.

Cross-team boundaries got crossed. A blocked team got unblocked. The team that originally owned the recipe got their backlog space back.

The FDE shape works.