TillyGen and Make

What this is about

Make builds automations as visual scenarios: modules on a canvas, connected by lines, with routers that split a flow into branches and filters that decide which branch runs. Its HTTP module speaks to any API, TillyGen's included, and its mapping panel reshapes JSON between steps. That fits production workflows with real logic in them: a schedule change should reach the crew channel and the client mail and the tracking sheet — but the client only on day-level changes, not on every shot swap. One scenario expresses that whole decision tree, visible at a glance.

An integration is good when nobody talks about it any more: the data is where it is needed and nobody exports anything.

What runs differently here

Where this differs from the general case:

• The HTTP module calls the TillyGen API on schedule or on webhook, and the response's JSON fields become mappable pills in every later module
• A router splits one plan event into audience branches — crew, client, archive — each with its own filter and tone
• Filters distinguish severity: shot-level edits stay internal, day-level moves also trigger the client mail
• Scheduled scenarios can fetch the current plan state every morning and post a daily digest instead of twenty single alerts

Step by step

This order gets you there fastest:

1. Sketch the decision tree on paper first: which plan events exist, who must hear about which, in what tone — the scenario just encodes this.
2. Start the scenario with a webhook or scheduled HTTP call against the TillyGen API and run it once to capture the response structure.
3. Add a router with one branch per audience and put a filter on each branch that checks the event's severity fields.
4. Map the JSON fields into each target module — message, mail, sheet row — reshaping dates and names into human-readable form.
5. Run it in watch mode through a real week; the execution log shows every branch taken, which makes wrong filters visible fast.
6. Freeze the scenario once it behaves, and document the one place where the plan's field names would break it if they changed.

Common pitfalls

What most often goes wrong in practice:

• A scenario that grew branch by branch until nobody dares touch it — the automation is now the least understood part of the production
• Silent failures: a filter eats every event and no one notices for two weeks that the client mails stopped

With TillyGen

Make distributes and transforms what the TillyGen API reports; it never originates plan data. If a scenario and the plan ever disagree, the plan is right and the scenario has a bug — that hierarchy is the design.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.