APIANT vs Tray.ai

Shared infrastructure means shared rate limits, shared incidents, and commingled customer data.

03 · A dedicated dev and production server pair, on your own domain, single tenant, from the first paid tier

The scenario

Third Coast Credit Union: 190,000 members, one circled questionnaire line, nine days

Third Coast Credit Union runs 41 branches and holds accounts for 190,000 members. Its vendor risk committee has sent back a 112-question security review with one line circled: confirm that member data and integration traffic are not commingled with other tenants, and name the domain the traffic terminates on. The board votes on the core-banking integration in nine days. Priya Raman, the IT director, has to answer that line in writing, and she cannot answer it with a shrug about the vendor's region.

Priya asks the AI what runs on her servers: a dedicated dev and production pair, her domain, no other tenant in the queue. She can check it herself, or shut them down.

The circled line on the questionnaire asks about commingling, and what Tray publishes in answer is a location rather than a tenancy: "A Tray instance can be hosted in one of the following Data Regions: US, EU, APAC", priced as "Team (optional add-on per region), Enterprise - all regions available as standard". Across the regional-hosting, on-premise and environment-setup pages we read, dedicated resources appear in one place, and the scope is the connector layer of the on-premise path: "A key benefit of the on-prem agent is that the connector nodes inside the Tray On-Prem Network are dedicated resources and not shared with other users." Reaching that path is an engineering project rather than a setting. Tray documents an agent install on Linux or Windows 64-bit, or AWS Transit Gateway, PrivateLink or VPC peering, or a site-to-site VPN which their own page describes as requiring "opening your firewall to inbound traffic from Tray" with "considerable technical overhead" that "will require the involvement of an engineering team". Their default subnet is fixed and has to be planned around: "Tray uses 10.200.0.0/25 by default. This cannot overlap with your VPC CIDR range." Dev and production separation is an account structure, not a server pair. Workspaces do it for ordinary automation, and for anything customer-facing Tray states: "it is not currently possible to create Solutions in shared workspaces. In order to manage multiple integrations you will need to set up multiple Tray orgs to act as e.g. dev, staging and prod." Each of those orgs is a separate identity boundary for staff, since "A Tray User can access one Organization in a given region per unique email address", with a plus-address modifier as the documented workaround. For the hostname question underneath the commingling question, the browser-facing and webhook addresses stay on domains Tray holds: embedded.tray.io, auth.tray.io and the trayapp.io webhook host, or, de-branded, Tray's wildcarded apexes "prefixed with your company name e.g. acme.integration-configuration.com".

A generated integration that is syntactically fine and semantically wrong reaches production, and nobody knows until customer data is wrong.

04 · A deterministic compiler that refuses structurally invalid work before it exists

The scenario

Halvorsen Mutual: 6,200 hail claims ride on a generated payments integration

Halvorsen Mutual writes crop insurance for 8,900 farms across Nebraska and Kansas. After a hail week in June, 6,200 claims queue up, average payout $18,400, and the integration that pushes approved amounts into the payments system was generated last month. It compiled cleanly and it deployed cleanly. Dee Ostergaard, the claims supervisor, is the person who learns whether it wrote the approved amount or the estimate into the payment field, and she learns it from farmers on the phone.

The AI's intent passes through a constrained schema; the compiler refuses invalid structures at the door. It then tests the build on a real saved claim and reads what reached the payment field. Dee can open that run too.

Tray does refuse a broken build, and the mechanism is good enough to state in their words rather than ours: "Validation runs in two layers, both server-side: every workflow-mutating call validates the affected steps before anything is written, and a whole-workflow audit checks that jsonpath references resolve, output shapes are correct, and structural conventions hold. The model can't write a malformed workflow." The per-call layer checks just the steps the change touched, which is the right design, and it arrives with Headless, which their pricing page lists under "Included in all plans". The published scope of that guard is structural: "jsonpath resolution, output-shape rules, structural conventions". A payout mapping that resolves cleanly and lands on the wrong field is well formed, so it passes. The check that separates wrong from malformed is a run, and Tray is candid about what a run is on their platform. Their own build-workflow skill states it: "trigger_workflow fires a workflow against the live Tray workspace, not a dry-run, not a sandbox. Each fire executes every step, creates an execution log entry, consumes API quota." Their plugin documentation says the same thing in longer form: "a Slack step posts a real message, a Salesforce step writes a real record, a webhook calls the real endpoint." So after a hail week, the evidence that 6,200 approved amounts are right is obtained by sending some of them and reading the log. On the promotion path there is a preview, "Call POST /core/v1/projects/{projectId}/imports/previews to analyze potential changes before deployment", which compares what a deploy will change rather than what a branch will do. And the log that holds the proof is on a package clock, 7 days on Pro, 7 with a 30-day add-on on Team, 30 on Enterprise, with their limits table listing "How long can logs be re-run for? | 7 days".

The same connector logic was being rebuilt per customer, and the copies diverged.

05 · Reusable building blocks: assemblies, modules, subassemblies

The scenario

Cardwell Staffing: 60 trusts, 60 drifting copies of one shift lookup

Cardwell Staffing places 2,300 agency nurses a week across 60 NHS trusts, each running its own rostering system. The logic that finds available shifts by ward was built once, then copied into all 60 integrations, and a timezone correction made in February reached 41 of the copies. On a Tuesday morning audit call, a trust liaison asks Marcus Ibe, the RevOps lead, to state which version of that lookup each trust is running today.

Marcus asks the AI which integrations run the shift lookup; it names the referencing assemblies and the automations using them. Built once, fixed once: all 60 trusts inherit it. He can walk the list himself.

Tray has genuine reuse by reference, and it is the mechanism they recommend for exactly the maintenance reason this row is about. Callable workflows are selected by name, and their guidance is direct: "it is highly recommended to use a callable workflow for each processing action. This will enable you to work with a set of simpler parent and child workflows which are easier to understand and maintain than one large sprawling workflow." Fix the callable and every caller gets the fix. Concede that cleanly. The question a sixty-trust rollout runs into is scope rather than mechanism. Tray's own environment guidance keeps the shared unit inside the project: "It is generally advised to make your projects 'self-contained' in that callable workflows and alerting workflows should be part of the project." Serving many customers from one build is the Embedded Solution model instead, and that is a purchase: "The Tray Embedded bundle is available to Enterprise customers as an optional add-on. Please contact your sales representative if you wish to activate the bundle." The other reuse unit Tray ships is a copy, and it is the one people reach for when the shared thing is a configured step rather than a whole workflow. "Snippets are pre-configured single or multiple workflow steps that can be re-used when needed", and the mechanism is the clipboard: "This will copy the snippet to your clipboard and you can then right-click and paste it anywhere in your workflow." Nothing published describes a pasted copy tracking where it came from, copies are independent objects by their own account ("Copying or duplicating a masked step - The copy is a new step and is not masked"), and the instruction before altering shared logic is bookkeeping: "We highly recommend you make a list of all the step dependencies associated before beginning any alterations." Proving the shared piece alone is also asymmetric: "For a fire and wait for response callable workflow, you can only replay from within the calling workflow."

Every vendor's API announces change differently, and picking the wrong mechanism means missed or duplicated records.

09 · Six ways a run can start

The scenario

Redwing Freight: nine carrier feeds, 1,400 tenders nightly, trucks double-dispatched

Redwing Freight, a Memphis brokerage, moves 1,400 load tenders a night across nine carrier systems. Each carrier announces change its own way: one fires a webhook on every touch, one exposes a polling endpoint with no updated-at field, one expects a long-lived listener that reconnects on its own. Night dispatcher Dana Whitfield has twice sent two trucks to the same dock because a carrier feed replayed a status it had already sent. She now starts her 10pm shift reconciling the tender log by hand before she dispatches anything.

The AI picks the right pattern per API and builds the trigger, or Dana's team picks it: polling for new records, polling for new-or-updated, manual webhooks, self-registering webhooks, service webhooks with event filtering, long-lived protocol listeners. Six vetted patterns either way, and which one a feed is using is visible on the trigger itself.

Mechanism coverage is not where this row turns, and it is worth saying so plainly. Tray documents service triggers, webhook triggers, scheduled polling with its own "Basic polling" and "Polling with last runtime" pages, and an event subscription model with delivery retries: "Tray will retry the delivery of those events with exponential backoff. Thus, you will not be losing any events even if your endpoint is rate-limited." A carrier that fires a webhook on every touch and a carrier with no updated-at field both have a documented pattern. The cost sits in the published ceilings around those patterns. Their limits table gives "Data that can be consumed by our Webhook Trigger | 1 MB", with file content going as multipart against "an overall limit of 10MB". A burst is rejected rather than absorbed: "If too many requests (i.e. several hundred per second) come in to your webhook trigger at once, Tray.io will respond with an HTTP 429 (too many requests) error." And a polling run that overruns its own interval loses the work behind it: "In a case where 3 attempts at starting a run are made while one is still completing, these runs are missed. They are not added to a queue." Two smaller taxes are worth knowing before a nine-system build. Filtering at the trigger does not save you the run: on events discarded by a connector-level filter, "Since all of the above events were processed by Tray, these will be billed." And proving a dedicated trigger means substituting it: "If you are using a dedicated Tray Service trigger then you will need to temporarily swap it out for a Webhook trigger."

6 trigger skills

Create-read-update-delete alone cannot express what modern APIs do.

10 · Seven action primitives, including calls that return computed or generated data

The scenario

Halvard Mutual: two claim-intake steps the company cannot itself explain

Halvard Mutual, a regional auto insurer in Ohio, takes 3,000 first-notice-of-loss claims a month. Two steps in intake are neither reads nor writes: a photo-damage model that returns a repair figure, and a third-party fraud score. Both sit inside a code block written by a contractor who left in March, so claims supervisor Renata Ozols cannot see what either step does without raising a ticket with an outside firm. Her adjusters are quoting repair numbers the company cannot itself account for.

Ask the AI for the fraud score and it builds the call as an invoke action, the primitive for operations that compute, transform, or generate. Or Renata's team builds it. Add, delete, find, get, list, update, and invoke: seven primitives, and either way the step opens as data rather than as a contractor's code block.

Tray reaches an RPC-style endpoint, and their generic step is unconditional about it: "The HTTP client connector allows you to make calls to any third-party API endpoints." Recent connectors ship a "Raw HTTP Request" operation for the same purpose. A damage-model call and a fraud-score call are both reachable. What that step gives up is published on the same page. The request is assembled by hand from the vendor's documentation: "In this case we have had to use the Airtable API documentation to find the URL of the endpoint we wish to access. We have also had to set an Authorization Header using the $.auth.api_key jsonpath." The response arrives untyped: "Parse response - Automatically generated as a string, this can be changed to make the response JSON or XML etc." The output schema does not exist until a real call has fired, since "The Output tab should update with new schema" is step five of their quickstart, after "Test the workflow". Paging is yours to build against a ceiling: "Tray has a page limit of 1 MB." Retry semantics are the part that bites on a scoring or inference call that rate-limits, because the failure does not present as a failure: "the 429 response will be contained within a Tray 200 response." Connector retry policy fires on an error, so a wrapped 429 gets none of it, and their guidance is to write the backoff yourself: "watch for 429 status codes within the response body and build in a retry mechanism." The waiting room is generous by comparison, "How long does the HTTP Client (Universal Connector) wait for a response? | 15 mins" against 45 seconds for a standard connector step, so a long inference call fits; it simply arrives as a string somebody has to type by hand.

7 action skills

A vendor's rate limit is the real constraint on a multi-location sync, and hitting it corrupts a run.

11 · Throttling at three levels: connector, action, and connection

The scenario

Alder Pharmacy: 310 branches, one shared rate limit, 2:40am pages

Alder Pharmacy Group dispenses across 310 branches in the north of England, every one of them syncing to a single supplier API that allows 120 calls per 10 seconds. Fourteen other automations draw on that same budget, and the arithmetic that keeps them inside it lives in one engineer's head. IT director Sunil Bhatt has been paged three times this month at 2:40am because a rate-limit rejection killed the nightly refill batch partway through, leaving branch queues short of data by the 8am opening.

Tell the AI the vendor's published limit and it sets the throttle, at connector, action, or connection level, or Sunil types it once himself. Either way the platform enforces it across every automation and every account touching that API, with queueing and backoff, and either of them can read the current setting back. One deployment runs 232 locations against a single 185-calls-per-10-seconds budget.

Fourteen automations drawing on one vendor's budget of 120 calls per ten seconds is arithmetic Tray leaves with you, in every workflow that touches that API. Their third-party rate-limiting page is direct about it: "If you are exceeding the rate limits of a 3rd Party you will either need to implement one of the above solutions, or you will need to arrange for your rate limits to be increased with the 3rd party." The solutions above that line are steps a builder places by hand: "adding a 1 minute delay between calls", "If implementing pagination you may need to set up an exponential backoff", and "A basic technique for integrations to gracefully handle limiting is to watch for 429 status codes within the response body and build in a retry mechanism." Their batching guidance repeats it: "you might need to make use of the delay connector to set e.g. a 10 second delay between batches." Why you watch for the 429 yourself is also published. A third-party rate-limit response does not reach Tray as a failure: "the 429 response will be contained within a Tray 200 response", so the connector retry policy, documented as "Retry 3 times every 40 seconds", does not fire on it, and the backoff is yours to write and to keep consistent across every workflow sharing that vendor. What Tray publishes as a throttle control governs the APIs they expose rather than a vendor's budget: "when creating an accept policy, you can set rate limits in the 'Throttle request' section at the bottom of the page." Their own platform ceilings are published at 30 requests per second and 1800 per minute, and workflow concurrency is set centrally: "Please contact support if you wish to increase concurrency." Across the pages we read, their Tray and third-party rate-limiting troubleshooting pages, the batching and queueing pages, technical limits, and usage and billing, nothing describes a shared budget per vendor connection enforced across several automations or child accounts.

Customers wanted one daily digest, not four hundred notifications.

17 · Collector: aggregate items into named buckets across many runs, drained on a schedule

The scenario

Kestrel Freight: 400 daily alerts, two big shippers asking to be unsubscribed

Kestrel Freight Brokerage moves 380 loads a day for 60 shippers out of Memphis, and every pickup, delay, and delivery event pings the shipper's contact. Two of its largest accounts asked to be removed from notifications entirely after one Tuesday produced roughly 400 emails. What they actually want is a single summary at 5pm listing every load and its status. The dispatch operations manager has been assembling that digest by hand each afternoon since March, and she is away next week.

The operations manager asks for one 5pm summary and the AI builds the collector: events drop into a named bucket all day, drained on the schedule. She can build the same bucket herself. It is a dedicated primitive, safe when two runs land at once.

Turning four hundred notifications into one daily digest means holding a day of events somewhere and draining them on a schedule. On Tray that store is the Data Storage connector, and its ceiling is published: "Storage limit under single key | 400 KB", with a "Nested depth limit | 32" and scopes that decide how long an accumulation survives ("Workflow scope: until deletion of the workflow", "Account scope: until deletion of the workspace", and current-run data held "30 days from execution"). A day of pickup, delay and delivery events for sixty shippers has to fit inside a 400 KB key, or be split across keys somebody has to name and reconcile. Their queueing page opens with a caution rather than a primitive: "Please be aware that building a queue may not be appropriate for your requirements." And where the digest has to be per end customer inside a customer-facing solution, their newer store is ruled out: "The current version of data tables cannot be accessed from within an end-user solution instance." The pages we read on this (queueing, chunking and batching, data tables, storing and retrieving data, and workflow alerting) present batching, queueing and storage as patterns to assemble and name no digest or aggregation primitive. So the shape of the answer on Tray is a workflow that writes into a key, a schedule that drains it, a per-recipient split, and a 400 KB budget to stay inside.

pattern-collector

"Follow up in three days" required an external scheduler and a second system to maintain.

18 · Snooze: pause a run until a future moment

The scenario

Tallgrass Mutual: three-day claim follow-ups riding on an unowned external scheduler

Tallgrass Mutual handles 6,200 auto claims a month in Iowa, and about one in five stalls waiting on a document from the insured. State rules put a clock on the claims supervisor: if the adjuster has not followed up within three days, the file ages into a regulatory bucket that carries a penalty. That three-day wait currently lives in an external scheduler a contractor built in 2023, which the present team cannot modify. It missed 34 follow-ups last quarter, and the audit is in November.

Ask the AI to hold the file for three days and it adds the snooze step; the supervisor can add that step herself. The run suspends for three days, or until next quarter, and resumes with its state intact. One system, one place to look.

A claim that stalls for three days and then picks itself back up is either something the platform does or a second system your team runs and monitors. Tray.ai does not document this. We searched their technical limits table, the batching and queueing pages, the polling-for-new-data pages, calling other workflows, the workflow-settings pages and the help bundle, and searched the full platform and developer documentation bundles for "snooze", which returns nothing. On that basis it is manual work rather than a platform behaviour. Two published mechanisms sit near it without being it. A Delay connector, which their docs use for short waits ("you might need to make use of the delay connector to set e.g. a 10 second delay between batches"). And the Fire and Wait for Response operation on the Callable response connector, which their limits table says has no timeout, "as a workflow could take a long time to complete". The second is a run held open for days rather than a job put down and picked up, which is a different thing to operate and a different thing to bill. The same limits page bounds whatever state such a wait would carry: data under Current Run scope is held "30 days from execution". The evidence you would need to prove what happened during the wait expires sooner, at 7 days of log retention on Pro and Team and 30 on Enterprise.

pattern-snooze

Some records must not sync until a person says yes, and the wait cannot block the platform.

19 · Human approval gates with a moderation queue

The scenario

Rowan Box Office: £500-plus refunds stuck in a support inbox before a storm

Rowan Box Office sells 1.2 million tickets a year for 90 regional venues, and refunds flow straight through to the payment processor and the venue ledger. After a cancelled festival produced £48,000 of refunds in one night, finance set a rule: anything over £500 needs a venue manager's yes before it moves. The head of support now parks those requests in a shared inbox and chases approvals by text, while every small refund queues behind them. Friday is a sold-out arena show with a weather warning on it.

Ask the AI for a gate above $500 and it adds the moderation step; the head of support can add it herself. The run pauses on a queue, a person approves or denies from a link, and the run resumes. Everything smaller keeps flowing.

Tray documents human approval, and that should be granted plainly. Their Agent Gateway pages list "Governance - Human-in-the-loop approvals, audit logging, security controls" and "Human-in-the-Loop Approval ... Request approval", and their tool comparison table marks "Requires approval" as available on workflow tools where connector tools have it unchecked. Their intelligent-automations page names "Human-in-the-loop approval workflows" as well. The cost is where that control lives and what it gates. The documented gate is Agent Gateway's, which their pricing page sells under the "Agent Development" add-on and which their staff switch on: "Agent Gateway access must be enabled at the organization level. Contact your Customer Success representative." What it approves is an agent's call to a tool. A refund parked until finance releases it is a different object: a record held outside the run, with a reviewer's link, a retention window, and an audit of who released it. For that second case the pages we read (Agent Gateway workflow tools and connector tools, intelligent automations, workflow settings, error handling, the advanced use cases and the help bundle) describe approval as a workflow you build. The parking, the link, how long a held record survives, and what happens to it when the reviewer does not click are design decisions that land on your team rather than settings you pick.

pattern-human-moderation

One monolithic automation became unmaintainable and untestable.

20 · Parent and child automation chaining with parameter passing

The scenario

Vosdal Precision: 64 untestable steps, and an 18-percent customer needs a branch

Vosdal Precision, a contract manufacturer with three plants in Ontario, runs order-to-cash through a single automation that has grown to 64 steps: quote, credit check, works order, shop-floor release, shipment, invoice. Any change to the credit-check rules means retesting all 64, so the applications manager tests none of it and edits at 5am on Sundays. Two plants now need a different shop-floor release rule, which puts a branch inside a branch that is already three deep. The customer asking for it is 18 percent of revenue.

The AI splits the 64 steps into small automations that call each other with parameters, or the applications manager does the split himself. Either way each piece tests alone, so a credit-check change retests one piece instead of all 64.

Splitting a 64-step order-to-cash flow into pieces is documented and recommended on Tray, for the same reason we recommend it: "it is highly recommended to use a callable workflow for each processing action. This will enable you to work with a set of simpler 'parent and child' workflows which are easier to understand and maintain than one large sprawling workflow." Concede that. What is thinner is proving one of those pieces without running the rest. Their isolation feature "allows users to isolate and test individual steps within a workflow", and their own bullets bound it: "This functionality is designed for running individual steps and does not execute full workflows or multi-step processes", "this feature is not intended for end-to-end integration testing", and "Testing a step within a workflow that could affect a third-party system will have a real impact". Anything holding state is excluded: "the data storage step with a scope of 'current run' cannot be used in isolation." Two consequences land on the person changing the credit-check logic. The evidence disappears: "No logs are retained for test runs. Exercise caution, especially when testing with production systems, as there will be no record of your actions." And the attempt is metered: "Each time you run a step in isolation it is billed as a single task." So the way to exercise the credit-check branch with its neighbours intact is to fire the workflow, which their own documentation describes as running every step against whatever it is wired to.

pattern-execute-automation

A customer's mapping requirements arrived as a 300-row spreadsheet, and hand-entering it was a week of error-prone work.

21 · Field mappings imported from a spreadsheet

The scenario

Harrowgate Press: 300 mapping rows to key in before October renewals

Harrowgate Press is migrating 210,000 magazine subscribers off a 1990s circulation system onto a new CRM, and the vendor delivered the field map as a 300-row spreadsheet: expiry codes, agent sources, gift-recipient flags, six renewal statuses that each mean something slightly different. The circulation director has one implementation consultant for four weeks, and hand-keying 300 rows into a mapping screen eats most of week one. Every keying slip surfaces later as a subscriber who stops receiving the magazine or gets billed twice. Renewal season opens on 1 October.

Hand the AI the 300-row file and it becomes the mapping directly: the AI reads it, applies it, and flags the rows that do not resolve. The consultant can key a row herself, or correct one the AI flagged, on the same screen.

Three hundred rows of expiry codes, agent sources, gift flags and renewal statuses have to get from the vendor's spreadsheet into the platform, and every row is a chance to transpose something. Tray.ai does not document this. We searched all seven Embedded data-mapping pages, the config slots page, managing CSV files, all nine mapping-data pages and the Embedded delivery-method pages. On that basis it is manual work rather than a platform behaviour. What is published is a programmatic route into an end customer's configuration rather than into a workflow's mappings: config data can be supplied on the end user's behalf as a configValues array passed with the upgradeSolutionInstance mutation. That is a script written against their GraphQL API, owned and maintained by whoever wrote it, and it moves values into slots that already exist rather than creating the mappings. Their own pages name the ceiling a 300-row map runs into: "Your solution requires the end user to map 100 fields in the configuration step, 100 fields can't fit in one page of the config wizard", with the recommended answer being to "build your own form experience, leveraging our API's". That whole surface is part of the Embedded bundle, which is "available to Enterprise customers as an optional add-on".

pattern-csv-mapping

The same API quirk was rediscovered every time, by whoever drew the short straw.

22 · A pattern library that persists institutional memory

The scenario

Cedarline Credit Union: nine years of API knowledge leaving in three weeks

Cedarline Credit Union serves 74,000 members in Alberta with a four-person integration team, and every project rediscovers the same two things: the core banking API reports posting timestamps in local time with nothing marking the zone, and the loan-status enum needs a lookup table that exists in one engineer's head. That engineer has been there nine years and has given notice. The IT director counted 11 live integrations resting on knowledge that was never written down. His replacement starts in three weeks.

The AI writes each solved quirk into a searchable library and checks that library before it builds anything, so the timestamp-zone trap is solved once, ever. Your engineers read and write the same library, which is what keeps the knowledge after its author leaves.

The two facts a four-person team rediscovers on every project, the API that reports timestamps with no zone and the field that silently truncates, have to live somewhere the next person finds them. On Tray the unit for a configured step is a snippet, and the mechanism is the clipboard: "When using the build interface you can save single or multiple workflow steps as 'snippets' to be re-used in any of your workflows", and "This will copy the snippet to your clipboard and you can then right-click and paste it anywhere in your workflow." Pasted copies are independent objects, which their log-masking page shows in passing: "Copying or duplicating a masked step - The copy is a new step and is not masked." So a correction to the snippet reaches the next paste and not the copies already sitting in the automations built last year, which is how two versions of the same hard-won fix end up in production. Their machine-readable memory is real and worth conceding: the tray-gotchas skill is a "Debugging guide for known edge cases and tricky surfaces" and tray-patterns covers "Workflow structure patterns". Those files are Tray's own, shipped as reference files in their public plugin repository, so what an assistant reads back next session is Tray's accumulated knowledge of Tray. Across the four Tray Headless pages, snippets, workflow documentation and the two augmented-development pages we read, nothing describes a store your own team writes to and the assistant reads on a later session.

patterns toolset · 3 tools

Occasionally a requirement is genuinely outside any data model, and waiting for a platform release is not an answer.

23 · A server-side scripting escape hatch

The scenario

Redbank Falls: a 1987 check-digit rule blocking a 30 September council deadline

Redbank Falls, population 88,000, is connecting its new permits portal to a 1987 mainframe that still holds property records, and that mainframe accepts fixed-width records ending in a check digit computed by a rule written out in a retired clerk's ring binder. Nothing in any mapping tool expresses it. The city's systems analyst has a council deadline of 30 September for online permit applications and a vendor quote of $140,000 to build a middleware layer for this one field. He is not going to get a platform release that adds a 1987 check-digit function.

Give the AI the ring-binder rule and it writes the check-digit logic into one script node and compiles it; the analyst can write that node himself. Either way code is an optional leaf inside a data document, never the foundation, and everything around it stays visible, testable and machine-editable.

Occasional code on Tray is not that occasional. The three jobs that most often reach for it are an operation the catalog does not carry, end-user field mapping, and a dropdown in a customer-facing config wizard. Of those three, one needs a support ticket to switch on and one needs the Embedded bundle. Field mapping is the clearest case. Tray's Embedded data-mapping introduction states the mapping itself is built as code: "This is done by making a Script connector-based workflow which maps the fields in the original service to the correct fields in the destination service." Where a wizard needs a dynamic list their connectors do not supply, the documented answer is Custom JS, behind a request: "If you wish to use Custom JS please contact support to arrange turning on the feature flag." The lighter surfaces are bounded or sold separately. Inline functions return scalars, with "Supported return types include: string (default), number, boolean." The SQL Transformer is offered explicitly as a replacement for code, "Instead of building complex, multi-step data-shaping logic using loops, list helpers, and script steps, you can now use a single SQL query", and it is gated on a conversation: "If you're interested in using this feature, please reach out to your Customer Success Manager or Account Executive." A missing operation, meanwhile, is not an exception at all but the CDK route past one or two endpoints, a TypeScript project on Node 18 with one namespace per organisation and a Jest test per operation, owned by whoever wrote it.

"It worked when I tried it" tested one path out of eleven.

26 · Branch-coverage test points

The scenario

Halden Mutual ships a claim-intake change with ten of eleven branches unwalked

Halden Mutual writes crop insurance for 6,800 farms across three Midwestern states. Their claim-intake automation has eleven branches: hail, frost, flood, partial loss, reinspection, denial appeal, and five more that fire a handful of times each season. Claims supervisor Dana Whitlock signed off on a mapping change in August because the hail path ran clean in the test. Harvest starts in five weeks and ten of those branches have never been walked since the change.

She asks whether the change is fully tested, and the AI answers from the branch test points the platform tracks, then walks the ones still unexercised. She can read the same list herself. Coverage is measured, not assumed.

Tray.ai does not document this. We searched the whole platform, developer and help documentation bundles for coverage, untested and paths tested, plus the Insights page under enterprise core, all four testing and debugging pages, the development-tips page and the Agent Builder testing page. On that basis, keeping score of which branches have actually been exercised is manual work rather than a platform behaviour, so the answer to "is the frost path proven" is what the team remembers. The single place "coverage" appears is about connector unit tests in the CDK, and Tray hands the decision to the developer: "in practice, a connector test's focus is more about making sure that operations are properly communicating with the underlying implementation instead of testing its functionality, but ultimately it is up to the developer to decide how much and what type of coverage suits a given connector best." The automated check that does run on every change is structural rather than behavioural. Tray describes their validation scope as "jsonpath resolution, output-shape rules, structural conventions", which catches a broken reference and not an untried branch, and the one execution route their agent surface has is a live fire: "Firing a workflow runs every step against whatever it's wired to ... a Slack step posts a real message, a Salesforce step writes a real record, a webhook calls the real endpoint. It consumes API quota and writes an execution log." Proving eleven paths that way means eleven real runs against real systems.

exec_get_branch_test_points

Synthetic test data does not contain the thing that breaks integrations.

27 · Replay a real execution on real data

The scenario

Fairmount Dental needs a six-week-old run to reproduce a billing failure

Fairmount Dental Partners runs 61 practices across the UK and syncs treatment plans into a central billing ledger. A patient's insurance pre-authorisation posted wrong on 3 July, and the practice manager in Leeds escalated it on 12 August after the third rejected claim. Reproducing it needs that exact run: an emoji in the surname field and a mobile number typed with a leading plus and two stray spaces. The run she needs happened six weeks ago.

She names the 3 July run; the AI re-executes it from the step that broke, its captured data intact, or she does it herself. The emoji in the surname and the mangled mobile number are in the test, because the real record is the test.

Tray does replay a real run, and it is one click from the log: "When you want to replay a run, simply hover over the run log in question, and a new button option will be presented to you... Note that when you replay a run, a new workflow run is activated... The original workflow run will still be present." On real customer data that is the right mechanism, and it should be conceded before anything else is said. The constraint is the window, and Tray publishes it per plan: "How long you will be able to access logs and replay associated workflow runs will depend on your package: Pro = 7 days from the last workflow run; Team = 7 days (30 days as optional add-on); Enterprise = 30 days." Their own worked example spells out the consequence: "When you do discover the error, say, the following Tuesday having not received the usual list update, you will be unable to re-run said log. This is because the run log itself is over 7 days old... PLEASE be wary of such instances occurring." A finance escalation that surfaces six weeks after the bad posting is past that line on every published plan, and the retention can also be dialled down further, since "The data retention period can be reduced to 1 day via an organization-wide setting." There is a documented route to a longer horizon, and it points off the platform: log streaming is "available regardless of your log retention period. This allows you to stream your workflow execution data to your own systems or SIEM so you can set your own retention period", which is an Enterprise line item and separately a paid add-on. The lighter test path keeps nothing to come back to: for steps run in isolation, "No logs are retained for test runs."

exec_restart_from_step

Testing a webhook-triggered flow meant asking a customer to go and click something in their system.

28 · Webhook replay from historical payloads

The scenario

Kestrel Freight cannot ask shippers to re-send tenders just to test a fix

Kestrel Freight Group brokers 4,200 load tenders a day out of Rotterdam, each arriving as a webhook from a shipper's system. Two of its largest shippers push a rate-confirmation payload shape that was never documented, and last month it began dropping accessorial charges worth roughly 18,000 euros a week. IT director Sanne de Boer has the fix written. Validating it used to mean emailing a shipper's operations desk and asking them to re-tender loads they already moved, and that is goodwill she cannot spend twice.

She asks for last month's tender; the AI finds the stored payload and re-fires it at the fixed automation, or she replays it herself and watches it process. No shipper is asked to re-send a load they already moved.

Replaying last month's live traffic is outside the window Tray publishes. Their limits table gives one line for it, "How long can logs be re-run for? | 7 days", and their debug-logs page gives the plan-dependent reading, 7 days on Pro, 7 with a 30-day add-on on Team, 30 on Enterprise. A payload shape that started arriving four or five weeks ago sits beyond both readings. The payload itself is kept for exactly this purpose while the log lives: "Tray stores this data to allow workflow steps to use previous step outputs and for replaying or re-running workflow executions as and when needed." So the mechanism is there and the retention is what binds, which is why the documented answer for longer horizons is to move the data off Tray: "Log streaming, available regardless of your log retention period. This allows you to stream your workflow execution data to your own systems or SIEM so you can set your own retention period." That is an Enterprise plan line and a separate add-on, and what it gives you is your own copy of the execution record in your own tool. Two related caps are worth knowing before planning around replay: the webhook trigger consumes at most 1 MB ("file content can be sent as multi-part http requests, with an overall limit of 10MB"), and data passing between any two steps is capped at 6 MB, "any more will cause issues."

exec_replay_webhook

Proving one shared component meant running nine automations.

29 · Test a subroutine in isolation

The scenario

Ashgrove Polytechnic must prove a shared sequence before Monday enrolment opens

Ashgrove Polytechnic enrols 19,000 students, and its intake, transfer, credit-recognition and bursary automations all call the same shared address-and-residency normalisation sequence. Registrar Priya Nandakumar needs one change to that sequence before enrolment opens Monday at 8am. Proving it today means dragging all nine parent automations through a full test cycle on a Sunday, with the enrolment team already off shift and a 30,000-applicant queue waiting on the other side of the deadline.

She asks the AI to prove the shared sequence; it runs the subroutine alone on controlled inputs and reports what came back. She can run it the same way herself. One run, not nine parents dragged through a cycle.

Tray does let you exercise one piece without running the whole thing, and says so in the terms a maintainer cares about: running steps in isolation "Eliminates the need to run entire workflows to test a change on just one connector." They also recommend the by-reference structure that creates shared logic to begin with: "it is highly recommended to use a callable workflow for each processing action." The bound is that isolation is per step, not per sequence. Tray states it: the feature "does not execute full workflows or multi-step processes... not intended for end-to-end integration testing; it solely verifies the functionality of individual steps." It also keeps no record and is metered, since "No Logs Retained" and "Each time you run a step in isolation it is billed as a single task." So a shared multi-step sequence is proven through the workflows that call it, and one shape of callable cannot be re-run on its own at all: "For a fire and wait for response callable workflow, you can only replay from within the calling workflow (i.e. not the workflow being called)", repeated in their help centre as "you CAN replay 'fire and forget' operations but CAN'T replay 'fire and response' ones". The same asymmetry shows up on their agent surface: their plugin's own notes say "Callable workflows can't be turned off directly. Tray prevents update_workflow_metadata({enabled: false}) on a callable to avoid breaking other workflows that depend on it." That refusal is sensible, and it also means an agent handles the shared unit through its dependents rather than directly.

exec_test_subroutine

The fastest way to an outage is a confident agent with production credentials.

30 · Production is read-only by default; writes gate on explicit confirmation

The scenario

Ravensbourne Credit Union weighs handing an AI agent production ledger credentials

Ravensbourne Credit Union serves 41,000 members and posts about 2,600 ACH transactions a night through its integration layer. IT director Marcus Adeyemi has been asked to let an AI agent work directly on those production integrations to clear a backlog of 30 change requests. Regulators audit every write to the member ledger, and one mis-sequenced deploy at 11pm becomes a reportable incident by the time branches open. He is being asked to hand production credentials to something built to act with confidence.

The AI reads production freely: run history, step data, assembly logs, the account changelog. The actions that reach a fleet are preview-first by design. deploy_to_accounts returns the deployment plan on its first call and writes when a human passes an explicit confirmation, not before, and the group kill switch and its restore behave the same way. Marcus can make those same calls himself, and the changelog shows what happened either way.

Tray is unusually straight about this, and the sentence to read to an IT director is theirs: "The plugin acts in your Tray organization as you: Once you sign in, the plugin operates with your Tray identity and permissions in the workspace you select during sign-in. It can create, modify, and delete projects, workflows, and authentications, and run workflows that have real side effects. What it's allowed to do is governed by the permissions you grant it in Claude Code." That last clause places the guardrail in the client rather than in the platform, and Tray draws the distinction itself: "The packaged plugin surfaces destructive actions for confirmation; a raw client applies only the guardrails you give it, so review what your agent is allowed to do." The in-canvas assistant is described the same way: "Does Merlin interact with my live data? Yes. Merlin will update and delete any records that you ask it to. It is recommended to first test Merlin on test data / sandbox environments." And the agent's one execution route is production traffic by design, since firing a workflow "runs every step against whatever it's wired to ... a Slack step posts a real message, a Salesforce step writes a real record" and "It consumes API quota and writes an execution log." A read-mostly posture is therefore something you assemble rather than switch on: sign the agent in as a restricted user under Tray's roles model, keep it in a workspace you are willing to lose, and rely on whatever confirmation policy the MCP client enforces. A night of ACH postings is not the place where the difference between a client-side prompt and a server-side gate is discovered.

Three hundred locations cannot each hold their own credentials and configuration.

32 · Master and child account architecture, with master-account routing

The scenario

Kestrel Pharmacy: 178 branches, one webhook endpoint, refills landing at 6:40am

Kestrel Pharmacy Group runs 178 branches across Ontario and Alberta, each dispensing on its own credentials. Refill notifications from the dispensing vendor all arrive at a single endpoint with a four-character store code buried in the payload. IT director Priya Raman keeps 178 credential sets straight and has one URL to route them through. At 6:40am the day's first refill batch starts landing, and every message has to reach the branch that can actually fill it.

A parent account governs 178 children: the webhook hits the master, which routes by store code to the right child, processing on that branch's own credentials. Priya asks the AI where a refill landed and admin_auto_search_exec_history answers across all 178, or she opens the run herself.

The documented equivalent on Tray is not an account hierarchy, it is a join you maintain. Their End User model is deliberately two-sided: "They should be stored in your own user database, and when they are created using the createExternalUser API they will be stored in your Tray Embedded account. They must be linked between these two databases using a common externalUserId." A four-character store code buried in a refill payload therefore becomes a lookup you write, against a table you keep in step with theirs. The other route, one workspace per location, has a ceiling published on the plan line: three workspaces on Pro, twenty on Team, unlimited on Enterprise. A 178-branch estate is Enterprise, or it is not workspaces at all. Tray.ai does not document this, meaning an account hierarchy in which a parent receives one endpoint's traffic and routes each event to the right child location by a key in the payload. We searched their org setup, workspaces and projects, user roles, Embedded end users, Embedded solution instances and environment setup pages, plus the workspace limits on their pricing page. On that basis it is manual work rather than a platform behaviour.

Re-authenticating per location does not scale past about twenty.

33 · Shared where it matters, isolated where it must be

The scenario

Southern Reef Dental: 96 practices, one CRM login, re-authorised by hand

Southern Reef Dental operates 96 practices across Queensland and New South Wales, all reporting into a single group marketing CRM. Every practice holds its own practice-management login, but the CRM is one company account whose token expires every 90 days. Practice manager Dan Whitlock has burned three weekends re-authorising connections clinic by clinic, and the group settles on four more practices this quarter.

One CRM credential, flagged shared, serves all 96 practices while each keeps its own practice login. Dan asks the AI whether the group token still authenticates: asm_test_api_connection. He can check by hand. Sharing is a toggle on the hierarchy, alongside shared settings and automations.

Sharing one credential across locations works on Tray. The cost is that it is shared with everything else in the same workspace. Their environment guide lists the granularity under Limitations: "Cannot limit auth access per project within an environment." Workspace auths are available to every project in that workspace, so the group's single CRM token and everything else in the workspace sit at one level of access. Concede the separate half, which Tray documents cleanly: in Embedded "it is possible to set a limitation so that an End User is forced to add a new authentication for a particular Solution Instance, and cannot choose from a list of already-made authentications." That is what per-practice logins need, and it is there. The sharp edge is the shared token's refresh. Tray publishes it: "any changes made to an authentication will generate a new auth slot id on the backend of the service", and a changed auth slot id sits on their own list of breaking changes. So rotating the one company credential moves the integration onto the per-customer upgrade path rather than the automatic one.

Shipping a fix to two hundred customers by hand takes a week and misses some.

34 · One-click deployment and upgrade to every linked account

The scenario

Halyard Ticketing: refunds broken at 186 venues before Friday's 10am on-sale

Halyard Ticketing sells box-office software to 186 venues, from 300-seat regional theatres to a 19,000-seat arena. A payment provider renamed a field overnight and refunds have been failing at every venue since 05:00. Head of support Marta Kovac has the fix in hand and 186 customer environments to get it into before Friday's 10am on-sale, when 40,000 seats go live at once.

Marta tells the AI to ship it: deploy_publish_folder, then deploy_to_accounts across the 186 venues, each returning its plan and writing on her confirmation, per-account results in front of her. She can run both herself. Staging is naming a subset on one call, and every prior version is kept, so a reversal is a redeploy rather than a rebuild.

Tray splits this into two jobs, and the split does not follow how urgent the change is. Cosmetic changes ride the automatic path: a non-breaking publish is "a lazy update, with a delay of approx 2 minutes from release", and "If a source workflow runs on a scheduled trigger it won't happen until the next scheduled run." Anything Tray classifies as breaking goes customer by customer: "Query all the instances of the solution using Get Solution Instances. Loop and upgrade each one using the upgradeSolutionInstance mutation." That mutation takes a single solutionInstanceId in their published Embedded API, with no batch form, and their Embedded endpoints are "rate limited at 30 requests per second or 1800 requests per minute", so the fleet push is a script you write, own and pace. The classification is where a 05:00 incident lands. Their breaking list includes an auth slot "linked to a new service version or environment (e.g. the Salesforce connector has been updated to a new version)", so moving to the connector version that carries the fix is breaking by their own definition, and instances flagged requiresUserInputToUpdateVersion need the venue to run the Config Wizard again. Reversal is documented as a forward publish. The Rolling back changes section runs two lines in full: "If breaking change due to auths, manual rollback only. Always need to publish new version manually in solution editor." Concede the preview, which is genuinely strong: their publish-preview API reports breaking changes and per-slot detail before you ship. It tells you what will break; it does not push the fix.

deploy_to_accounts

A change made things worse, and there was no way back.

35 · Version history, comparison, and rollback on a live integration

The scenario

Foothill Co-op: guardian records merging across 41 districts, enrolment week opens 07:30

Foothill Education Co-op moves enrolment records between a student information system and the rostering tools of 41 school districts, 216,000 students in all. At 21:40 the night before enrolment week, integrations lead Yusuf Aldridge pushed a change to how guardian contacts are matched, and registrars in six districts are now seeing siblings collapsed into one record. He needs to know exactly what changed and be back to last night's state before offices open at 07:30.

Yusuf asks the AI what changed, and auto_compare_versions diffs tonight's committed version against last night's, naming the guardian-matching edit. He can read that diff himself. Getting back is a redeploy of the kept good version to the 41 districts, plan returned before it writes.

Two clocks, and the shorter one is the one you need at 21:40. Tray publishes both under version history storage: "Edit history: Viewable up to 12 months. Rollback feature: Can rollback to a previous workflow version up to 30 days prior to your current changes." Their own worked consequence is on the page: a change older than thirty days stays visible in the record and cannot be reversed. The versioning page repeats the ceiling. Concede what a version is, because it is real. Tray describes versions as commits, with an author, a change list and a restore. What they do not publish is a comparison of two chosen versions at any granularity. What a version shows is a count grouped one level above the step, "Changes are grouped by project assets, such as: Workflows / Project configuration ... / Solution", rendered as created, updated and deleted totals you then drill into. Two published caveats attach to the restore. Versions are snapshots someone has to remember to take, "save versions at key points during the development, similar to committing code", and the snapshot has holes: "Note that Datatables, Vector tables and API management are not yet supported. E.g. if a workflow refers to a datatable, the references will be saved but the datatable itself will have to be recreated manually."

Support needed to see a customer's runs without being able to change them.

37 · Role-based access with account-level permissions

The scenario

Rowan Yards: 340 buildings, 14 owners, all-or-nothing access, audit in five weeks

Rowan Yards manages 340 residential buildings for 14 institutional owners across three states. Regional managers are cleared to see their own thirty-odd buildings and nothing beyond them, and one owner's contract forbids staff on another portfolio from viewing a single record. When rent posting fails, the support desk has to inspect the run without being able to change owner data. Compliance officer Tomas Berg has an audit in five weeks and access today is all or nothing.

Administrators, builders and viewers are scoped by account: a regional manager sees their thirty-odd buildings, Tomas sees all 340, support reads a failed posting without touching owner data. Ask the AI and it stays inside that scope, dependency lookup included, with admin_account_changelog as the audit.

Roles on Tray stop at the workspace boundary. Their environment guide lists it under Limitations: "Unable to assign different roles to users per project", next to "Cannot limit auth access per project within an environment." A regional manager cleared for thirty buildings and nothing beyond them has to be given a workspace of their own, so the estate ends up cut into workspaces to match the permission map rather than the work. Above that line the scope is wide by design, and Tray's own release note says so: "Admin role grants access to ALL workspaces, not just the originally selected one." Some day-two data sits behind that role. Usage information is "limited to users with Admin or Owner roles", and masking, unmasking or revealing step data is restricted to Admins and Workspace Admins, as is running a step that has masking applied. Concede the read-access support case, which Tray handles properly: the Viewer role has read access to logs, and replay is available to Owner, Admin and Contributor while Viewer is excluded. That half of the requirement is theirs.

An API deprecation notice arrived, and nobody knew who was exposed.

38 · Fleet-wide impact analysis: which of my customers use this connector, this app, this operation

The scenario

Aldergrove Underwriting: carrier API retires in 90 days, exposure list missing

Aldergrove Underwriting, a managed general agent in Ohio, connects to 74 carrier and claims systems on behalf of 1,900 broker partners. On a Tuesday afternoon its largest carrier emails that v1 of the claims API retires in 90 days. Claims systems manager Rosa Ibarra has until Friday to name which integrations, which broker accounts, and which nightly jobs touch that endpoint, and today that list does not exist.

The carrier emails that v1 retires in 90 days. Rosa asks the AI who is exposed: admin_auto_search_by_app names every automation on that app across the broker accounts, asm_find_referencers the assemblies depending on the connector, permission-scoped. She can search herself. Minutes, and it is the migration worklist.

Tray answers this for authentications and leaves it open for the thing that actually changed. Their connector policy is published and deliberate: "When a new connector version is available and you are using it in a workflow, you will need to manually update it yourself. We do not allow automatic version updates because there is a risk that it may break your workflow." There is no watchlist to lean on either, "it is currently not possible to subscribe to updates for a particular connector", and the notification channel is a newsletter: "You will know there is a new version of your connector (or trigger) when it is mentioned in the latest Release Notes publication." So the 90-day deprecation notice arrives and the exposure question is answered by hand. Step Dependencies exists, but Tray scopes it to one workflow and calls it "A visual aid", and their instruction before a version change is bookkeeping: "We highly recommend you make a list of all the step dependencies associated before beginning any alterations." Their product page's claim of "one maintained connector library, always up to date" sits beside that policy, and a reader should weigh the two. Concede two genuine dependency queries, both recent. An authentication's information page lists the workflows that depend on it, shipped July 2026, and the Embedded slots usage modal shows "exactly which workflows and steps each slot is used in." Neither answers which workflows use a given connector operation.

Transient failures were treated as fatal, and genuine auth failures were retried forever.

42 · Error policy control: which errors deserve retries, and which must stop

The scenario

Kestrel Freight: 340 overnight load tenders dropped, trucks idle by 6am

Kestrel Freight Partners, a freight brokerage in Rotterdam, tenders overnight loads to 1,900 carrier systems between 1am and 5am. At 03:10 a carrier gateway returned a run of transient 502s and 340 tenders were abandoned as fatal, while on a different lane an expired token was retried every 90 seconds for six hours until that carrier's account locked. Joran, the night dispatch supervisor, has until the 06:00 driver call to work out which loads are actually covered. Trucks that sit unassigned past 07:00 come off the contract rate.

Ask the AI to retry the 502s and stop the expired token, or set the lists yourself: retryable error classes are tenant-wide, and auth failures on named domains get carve-outs. Shutoff is a policy on record, not a surprise you discover.

What you can set on Tray is a per-step mode, not a retry policy. The three modes are Stop workflow, Continue workflow and Manual. Which errors retry, how many times, and how long between attempts are published as platform behaviour rather than as settings your team owns. Their limits table is explicit about it: "Service connector API returns an error | Retry 3 times every 40 seconds | Retries 3 times only if set to stop workflow, error handling retries 0 times", and "Wrong user input (e.g. wrong jsonpath) | Doesn't retry regardless of error handling". Platform-side failures get their own fixed schedule, "Retries 15 times regardless of error handling", with the delay growing until "10th time will wait for 30 minutes". Kestrel's 03:10 carrier wobble therefore gets whatever the step's mode gives it, and the counts and intervals stay where Tray set them. In Tray's favour, they publish that this work is free: "Retries as explained in this table are not charged." The awkward case for a freight gateway is one Tray documents separately. A third-party throttle does not arrive as an error at all: "the 429 response will be contained within a Tray 200 response", so connector retry does not fire on it and the backoff is something you build into the workflow. We searched technical-limits, error-handling, manual-error-handling and the third-party error-handling pages for an account-level list of which status codes or error strings are retryable, and their documentation publishes none, so which failures count as fatal is decided step by step by whoever last edited the step.

/alert-handling

After an upstream outage, hundreds of records needed reprocessing, and there was no safe way to do it in bulk.

43 · Retry inspection and bulk retry

The scenario

Halden Pharmacy: 2,600 failed refill requests, patients arriving Monday morning

Halden Pharmacy Group runs 118 high-street stores across the north of England, and its prescription-refill hub was unreachable from 13:00 to 17:20 on a Saturday. In that window 2,600 refill requests failed on the way to the dispensing system. Priya, the pharmacy operations manager, has Sunday to get them through, because on Monday patients walk in expecting scripts that were never queued. Re-keying 2,600 records by hand is not a plan, and she has two staff available.

Ask, and the AI lists every failed run, shows what each was carrying, and retries them in bulk once the cause is fixed. Priya can work the same surface herself, at 2,600 or at any scale.

Reprocessing Halden's 2,600 failed refills is per run work on Tray, inside a published window. Replay is documented at two granularities and both are singular: "In your workflow logs it is possible to re-run either: An entire workflow run (using the left-hand column…) / An individual workflow step (using the right-hand column…)". The action itself is a hover: "When you want to replay a run, simply hover over the run log in question, and a new button option will be presented to you." The clock is the harder constraint for a Saturday outage. Their limits table sets "How long can logs be re-run for? | 7 days", and the log window behind it is package-dependent: "Pro = 7 days from the last workflow run; Team = 7 days (30 days as optional add-on); Enterprise = 30 days". Shared logic narrows it again: "For a fire and wait for response callable workflow, you can only replay from within the calling workflow (i.e. not the workflow being called)." On selecting many failed runs and replaying them in one action, their documentation publishes no statement. We searched both debug-logs pages, development-tips, the RBAC matrix in users/roles (which carries a "Replay executions" column with no bulk notion) and the platform API index, and swept all three documentation bundles for bulk retry, replay multiple and re-run multiple. On that basis a 2,600 record catch-up is per run work rather than a platform behaviour, and it has to happen inside the seven days.

exec_retry_failed

A misconfigured run was hammering a customer's API, and the only remedy was waiting.

44 · Halting a runaway execution mid-flight

The scenario

Loftgate Ticketing: a looping sync burns an arena's API mid-onsale

Loftgate Ticketing in Melbourne sells for 240 venues, and at 14:20 on the biggest onsale of the quarter a misconfigured seat-hold sync started looping, firing thousands of calls a minute at a 12,000-seat arena's box-office API. The arena's operations lead is on the phone saying she will revoke the API key. Dane, head of platform, watches the run count climb while the sale is live and 40,000 fans are in the queue. Every minute the loop keeps going spends rate allowance the sale itself needs.

Ask the AI to stop it: one call halts the runs in flight, a second deactivates the automation so nothing new starts. Dane can press both himself, while the sale is still live.

Tray publishes a kill switch and it is core rather than an add-on, which is worth saying before the limits: "if you need to immediately stop all executions of a workflow you can do this with the 'Stop all executions' button". Individual runs can also be stopped from the logs view. Two published facts about that button are parity rather than argument, and it is better to say so than to have a reader discover it. Their stop lands at a step boundary, "All running executions of the workflow will be stopped once the current step for each execution is completed", and a step is a bounded unit rather than an immediate one, with connector timeout at "45 seconds OR 120 seconds if built and deployed by you using CDK" and the HTTP Client at "15 mins". APIANT interrupts a run at the next step boundary too. Nothing in this row turns on that. What it turns on is which of the two controls an agent can reach, and how wide either one goes. The button covers what has already started: "This is not the same as the 'disable' button as it only stops executions that started before the button is pressed. To stop all past and future executions this functionality would need to be used alongside the disable workflow functionality." That stop is a UI action, with no endpoint in either published OpenAPI spec, trayapi.yaml or embeddedapi.yaml, and no tool on the agent surface. The disable is different and should be conceded: it is agent-callable per workflow through update_workflow_metadata, and refused on shared logic, where their plugin's own notes say "Callable workflows can't be turned off directly. Tray prevents update_workflow_metadata({enabled: false}) on a callable to avoid breaking other workflows that depend on it." Both controls are scoped to one workflow, so the intervention at 14:20 is a person in the builder for the runs in flight, plus a per-workflow disable for the next ones.

exec_halt

Silent backlogs: everything looks healthy, and nothing is moving.

45 · Visibility into webhooks received but not yet processed

The scenario

Ridgeway Environmental: 430 pickup reports stalled, trucks already left the yard

Ridgeway Environmental holds 61 municipal waste contracts across Ontario, and missed-pickup reports arrive from city portals as webhooks that feed route reassignment. At 08:10 on a Thursday, Marlene the dispatcher discovers 430 reports arrived overnight and never moved past the door. Every status board she has was green. The trucks rolled out of the yard at 05:30 without the reroutes, and the cities charge a penalty per street left uncollected.

Ask what arrived and never ran: the AI returns the received-but-unprocessed queue, 430 events, and Marlene sees the same view unprompted. Stuck work shows up before a customer notices the gap.

What Marlene needs at 08:10 is a list of events that arrived and never ran. Tray.ai does not document this. We searched both debug-logs pages, technical-limits, the help centre's working-with-logs and general-troubleshooting pages, the developer notes on working with webhooks and the queueing page under advanced use cases, and swept all three documentation bundles for unprocessed, dead letter and undelivered. On that basis reconstructing the backlog is manual work rather than a platform behaviour. What their documentation does publish about overflow points the same way. A source that outruns a webhook trigger is turned away rather than held: "If too many requests (i.e. several hundred per second) come in to your webhook trigger at once, Tray.io will respond with an HTTP 429 (too many requests) error", with the instruction to "throttle requests appropriately at the source third-party service". Overlapping scheduled runs are dropped in the same spirit: "In a case where 3 attempts at starting a run are made while one is still completing, these runs are missed. They are not added to a queue." On the Trigger API side, undelivered events are retried and still charged: "Events where Tray attempted delivery but your endpoint doesn't respond after retries… these will be billed." So for Ridgeway's 430 missed-pickup reports, the record of what never ran sits with the city portals and with whatever the team reconciles by hand, rather than in a view inside the platform.

exec_list_unprocessed_webhooks

Correlating a failure across accounts meant reading logs by hand.

46 · Cross-tenant search by the data itself

The scenario

Ambervale Insurance: one claim lost across 74 broker accounts, clock running

Ambervale Insurance Services, a Dublin managing general agent, handles claims for 74 broker partners, each in its own account. After a hail event, claim reference AV-2291884 was acknowledged to the policyholder but never reached the loss adjuster, and the regulator's five working day acknowledgement clock runs out on Monday. It is 16:00 on Friday, and Eoin, the claims supervisor, does not know which of the 74 accounts that reference passed through.

Ask with the claim reference and the AI searches every account at once for that value, returning the runs that touched it. Eoin can run the same search. Correlation across 74 accounts is a query, not a shift.

Correlating one claim reference across 74 broker accounts is work you do in a tool you supply. Tray's documented log filter is scoped to a workflow, and the sharing unit says so: "To share your logs filter just send the workflow URL to the user in question". Insights filters by workspace, project, solution instance and workflow, not by a value inside a payload. Their published answer for the estate-wide question is export: "you can use our log streaming functionality to send logs and events to an external source such as Datadog which can be used to build customized dashboards." That is a real escape hatch and it deserves credit, including on retention, since streaming is documented as available regardless of the log window your package gives you. It is also a separate purchase, an Enterprise plan line item and a paid add-on, and the index you end up searching is a system your team buys, runs and secures. Inside the platform, their documentation publishes no statement on searching every workspace by a value inside a payload. We searched both debug-logs pages, log-streaming, Insights, the help centre's working-with-logs page and organisation-management/managing-workflows. On that basis finding claim AV-2291884 across 74 accounts is either a per-account log search in the package's window or a query against your own exported copy.

Diagnosis stalled waiting for someone with database access.

47 · Ad-hoc data queries to validate a hypothesis

The scenario

Northfell Polytechnic: 260 students without timetables on day two of term

Northfell Polytechnic in Manchester enrolled 18,400 students this term, and the overnight sync into the student records system left 260 of them without timetable records. It is 07:40 on day two of term and a queue is already forming at the registry counter. Alison, the registrar, has a theory that it is confined to the part-time apprenticeship cohort at one campus, which would change the fix entirely, and she cannot test it without someone who has database access. Enrolment records are what the funding return is built from.

Is it the part-time cohort at one campus? The AI answers in seconds with a guardrailed read-only query, and Alison can run the same query herself. Tested in the meeting, not in a database ticket.

At 07:40 the question is which 260 students and why. Tray has SQL, and it is pointed at a different target: the SQL Transformer works by "enabling you to run SQL queries against data loaded from files within your workflows". It queries the data a workflow loaded, not the history of what the workflows did, and it is gated behind a Customer Success conversation as part of the data engineering add-on. The published surface for operational questions is Insights, and it is a set of KPI cards: "Active Workflows / Task Runs / Data Volume / Solutions / Solution Instances / End Users", each with "a trend metric that shows the percentage change compared to the previous period". Useful for a weekly review, and not the shape of a question about 260 named records that went missing overnight. On ad-hoc queries against your own execution history or platform metadata, their documentation publishes no statement. We searched the SQL Transformer page, Insights, usage and billing, the logs and debugging section and data-tables. On that basis the 07:40 answer is assembled by reading run logs workflow by workflow, and by whoever has the rights to do it, rather than asked as a question.

admin_sql_query · read-only

Capacity and billing questions had no ground truth.

48 · Health, usage, and task totals per tenant and per account

The scenario

Trellwood: quarter close, 380 agency accounts, disputed usage invoices

Trellwood is a workforce-management SaaS in Austin serving 380 staffing agencies, and it bills on synced placement volume. Deb, the controller, is closing the quarter with two agencies disputing their invoices and one that appears to have grown fourfold without ever moving off its entry plan. The numbers she is invoicing against were assembled by hand from three exports, and she cannot tell a heavy customer from an erroring one. Revenue recognition sign-off is due Thursday.

Ask which accounts are heavy, erroring or growing: the AI returns per-account health, usage and task totals across all 380. Deb's team queries the same numbers and exports them to your monitoring stack.

Concede this one substantially. Tray's usage dashboard breaks down by customer where Embedded is in play: the tabs run "All Tasks", "Workflow Tasks", "End User Tasks", "Connectivity API Tasks" and the token equivalents, and the filter names the customer: "The Solution Instance filter... allows you to filter by the available solution instances in that solution, with each listing showing the name of the end-user and the solution instance ID." Per-workspace task caps exist, and entitlement alerts fire at 80% and 100%. The retention window is not the constraint on this row either: the per-customer view needs Embedded, Embedded needs Enterprise, and Enterprise insights run 180 days. What Deb cannot do at quarter close is put those numbers anywhere. Tray states it plainly: "It is not currently possible to build Tray workflows which monitor and report on usage", with access "limited to users with Admin or Owner roles". So the controller reads a dashboard, under a role that also carries write access to the estate, rather than her billing system receiving a feed she can reconcile against invoices. Where AI work meets the invoice, the conversion is support-mediated: "Token-to-task conversion ratios are available from customer support, and we may add UI support for viewing these conversions in the future", with their own worked example showing the multiplier ("total_tokens": 2167, "tray_tasks": 108.35). On the Connectivity API side, "Can I get a view on the number of billable calls we are making? Not yet - your CSM will assist you in providing regular reports." For two disputed invoices in the middle of a reconciliation, that is a support thread on the critical path.

Support asking customers for passwords is both a security problem and a delay.

50 · Operating inside a customer account without their credentials

The scenario

Rowanbridge: 640 dental practices, and support still asks for logins

Rowanbridge, a practice-management SaaS in Toronto, serves 640 dental practices. At 08:15 a practice manager in Calgary calls: recall reminders stopped going out on Friday and she has 90 patients unconfirmed for this week's chairs. Nadia, the head of support, knows the current playbook is to ask the manager to share her login or wait two days for an engineer, and the security policy Rowanbridge sells against forbids the former. Each day the clinic runs on unconfirmed appointments costs it chair time it cannot recover.

The AI switches into the Calgary account's context with its own audited access, sees what the practice manager sees, and fixes the recall automation there. Nadia's team switches in the same way, and no password is ever requested.

Concede the control Tray publishes, because it is the right one to have. "Tray's Support Access feature allows you to determine when our support team can access your workflows", with organisation-level options "User Controlled / Always On / Disabled", a recommended time limit, and sessions attributable in the audit payload through impersonatedBy. No password changes hands. Concede the visibility too, because their structure gives it. In Embedded the end customer holds no Tray account and the solution instances run in the partner's own organisation, so a Rowanbridge engineer opens the workspace logs and Friday's runs for that practice are there, filterable per workflow and searchable inside the payload: "Clicking on the search box for runs and steps will bring up a list of filters", and "Searching logs can be very useful in cases where you are trying to find the exact location of a piece of data within a complex payload." What is not published is the shape that makes it a support workflow rather than an expedition. Tray.ai does not document a per-customer view across workflows, or a role narrow enough to give a support engineer that view without workspace-wide rights. We searched the support-access-controls page, users/roles, the Embedded key-concepts pages on end users and solution instances, and Insights. Their own environment guide states the role limit, "Unable to assign different roles to users per project", next to "Cannot limit auth access per project within an environment." On that basis, assembling one customer's picture at 08:15 is manual work rather than a platform behaviour. What their documentation offers for acting on the customer's behalf is configuration rather than diagnosis: "you can run the upgrade on behalf of End Users by: Running the Config Wizard on their behalf, and just selecting the same auth on the appropriate screen", through a shareable link that is "valid for 5 minutes".

admin_switch_account

Configuration UIs were bespoke front-end projects, every time.

53 · Form depth: an element catalog, reusable patterns, validation, live field refresh, embed codes

The scenario

Palletworks: a carrier setup screen promised against a nine-week front-end backlog

Palletworks, a freight-brokerage SaaS in Rotterdam, is rolling a carrier-billing integration out to its 260 broker customers. The setup screen has to pull each broker's live carrier list, validate SCAC codes before anything saves, and hide half its fields unless the broker uses a factoring company. Their two front-end engineers are nine weeks deep in an unrelated backlog, and the head of product promised the screen to the three largest brokers, whose renewals all land in the same week.

The AI assembles the setup screen from an element catalog and saved patterns: input validated before it saves, choices pulled live from the customer's systems, embed code returned. Adjust it in the designer yourself; the same form either way.

The wizard covers an ordinary configuration screen well, and the two things this scenario turns on, validation before anything saves and a screen that stays usable at scale, are the two Tray routes elsewhere. Grant the building blocks: auth slots, config slots, screen elements, and dropdowns backed by DDL lookups that read the broker's live carrier list with the broker's own credential. Validation is the thin part. Field-level logic in the wizard is Custom JS, and Custom JS is a ticket: "If you wish to use Custom JS please contact support to arrange turning on the feature flag." Where a lookup does not exist, the documented fallback opens the field rather than constraining it: "Allow custom values: If checked, the end user can write a custom value in the dropdown list", with Tray's own note that it is "turned off by default as, with some service operations, it can cause errors by allowing users to enter invalid values." We searched their config-wizard, config-slots, auth-slots, delivery-method and Custom JS pages and found no published declarative validation rule set on a config slot. Scale has a published ceiling and a published answer, and the answer is a front-end project. Tray uses 100 mapped fields as the worked case, and the route from there is "build your own form experience, leveraging our API's". Taking it drops the mapping surface with it: "you won't be able to use core Tray features like Data Mapping or Custom JS as they can only be used with the config wizard."

A chatbot that cannot act is a deflection tool, not an integration.

55 · Conversational agents with goals and tools, the whole platform behind them

The scenario

Aldergate: a resident agent that answers at 11pm but cannot act

Aldergate, a property-management SaaS in Toronto, ships a resident chat agent to 1,900 building managers. Last month it handled 6,400 conversations and 2,100 ended as after-hours callbacks: when a tenant asks at 11pm to move Thursday's plumbing visit, the agent can offer a help article and an on-call number, and that is the end of what it can do. The head of support is now being asked why an agent the company markets as an assistant still wakes a superintendent up.

The AI builds the agent you ship: explicit goals, scoped tools, each tool an automation you can open and read. Or you wire the goals yourself. It acts through the same governed engine as everything else: real writes, approval gates, full logging.

An agent that takes action exists on Tray, and the part this scenario turns on, a resident chat surface inside your product with your name on it, is code you write against an endpoint on a Tray host. Grant the acting part: Merlin Agent Builder gives agents workflows as tools, which is the distinction that matters, and their docs put it plainly, "Let your agent perform tasks by running chosen workflows, everything from running data queries to creating tickets to sending notifications." The published channels are Slack, Microsoft Teams and an HTTP endpoint, and the endpoint is what a branded widget would have to be built on. We searched Agent Builder's interaction-channels, getting-started, configuration, tools, testing and logs pages, plus the platform, developer and help documentation bundles, for a drop-in brandable web chat widget, and found no published statement. Access and diagnostics are both narrow. Every page of the section carries the same gate, "If you're interested in this feature, please reach out to your Customer Success Manager or Account Executive", and it is sold inside the Agent Development add-on. Agent logs are an "Early Access Feature" that is "currently available to a limited set of users and may change before general release", and in testing there is "No persistent history, each test session is independent." For 1,900 building managers whose tenants type at 11pm, the operating record is the part that has to be there.

An integration layer that shows a supplier's name tells your customer who really built it.

56 · Full white-label: your brand on the interface, your domain on the endpoints

The scenario

Fenmark: a 1.4M insurer deal meets question 41's hostname list

Fenmark, a claims-management SaaS in Des Moines, sells to 130 regional insurers and is 48 hours from signing a 22-state carrier worth 1.4 million dollars a year. Question 41 of the carrier's security questionnaire asks the IT director to list every hostname claim data touches, and Fenmark's VP of engineering knows the webhook receiver and the authorization callback both answer on a domain carrying someone else's name. The claims supervisor who championed Fenmark internally is about to be asked who that other company is.

Ask the AI which hostnames the integration answers on and it lists them off the connectors and the embed code. Every surface a customer's IT team inspects, the screens, the webhook URLs, the authorization callbacks, carries your name, at every tier.

You can take Tray's name off most of what your customer sees. What no published mechanism gives you is question 41 answered with hostnames you own. Concede the white-labelling, because it is genuine: the end customer holds no Tray account, no Tray-branded email reaches their inbox, and no tray.io hostname needs to appear in your own application's API calls, since "The Tray GraphQL API is a backend API only and calls must be invoked server-side. Client-side Javascript calls to the API should not be made as they will be blocked by CORS." What is on offer is de-branding on domains Tray controls. The wizard and auth dialog default to embedded.tray.io and move into a slot in a wildcard, and webhook receivers work the same way with the verb left in Tray's hands: "If you wish to remove the trayapp.io suffix it is possible to use the de-branded *.integration-hook.com suffix instead... You can then confirm before you are allocated an integration hook url." There is no CNAME, no DNS verification and no domain-add flow in the Embedded documentation. The Whitelabelling section runs to five pages, and none of the five documents a domain you own; two of them document substituting Tray's own wildcard apexes for Tray's default hostnames. The OAuth callback is the surface most likely to keep the vendor's name in the address bar, and Tray publishes the condition: "If the service does not support the entry of multiple redirect urls for custom apps in the US, it will be more difficult to use custom whitelabelled url domains. This is because Tray will only authorize apps which use the default https://auth.tray.io/oauth2/token redirect url." Where that applies, their documented fallback is "an alternative (but not 100% whitelabelled workaround)" that sends the browser back to auth.tray.io. API management is explicit: "It is not currently possible to whitelabel the base url for your API management projects." Their use-case page promises "No third-party logo, no second login, no hand-off to a vendor's portal", and even that page claims no customer-owned domain. So the list the IT director hands the carrier reads: your domain for your app, plus a configuration host, an authentication host and a webhook host on three apexes Tray allocates.

Depth and focus are in tension: an AI drowning in tool definitions gets worse, not better.

58 · A deep tool surface, activated on demand

The scenario

Halvard Logistiek: one integration lead retuning load tenders before a 3,400-load weekend

Halvard Logistiek, a Rotterdam freight brokerage moving 3,400 loads a week, runs 61 automations across nine carrier APIs with a single integration lead, Sanne de Vries. At 16:40 on a Friday she asks the AI to retune a load-tender mapping before the weekend peak, and that one session has to touch the connector, the automation, a test run, and the alert rules. Every irrelevant tool put in front of the AI is another way for it to reach for the wrong one on a change 40 dispatchers depend on by 05:00 Monday.

Sanne asks for the retune and the session loads that procedure with the tools it needs, the connector and mapping edits, a test run against real data, the alert rules, not all 138. The rest stay one request away when the job widens. Or she makes the same edits in the editor herself, on the same automation either way.

Tray publishes the problem and hands the remedy to the operator as a design decision made up front. On the same page they put a figure on it: beyond 15 to 20 tools per MCP server they say clients take longer to select the correct tool, selection accuracy decreases, and the risk of incorrect invocation rises. That page covers the MCP servers a Tray customer publishes for their own agents, which is the Agent Gateway add-on, and it is the clearest published statement Tray makes about tool crowding. Where an operator wants a narrower catalog, Agent Builder's control is a switch someone throws: "When a tool is disabled, the agent won't see it or consider it when selecting tools to complete a task." On the Headless surface itself, 24 tools is a compact catalog and the skill routing is real: "The plugin loads the right skill automatically based on what you ask." What that routing changes is the instructions the model reads. The tool surface behind it stays as it is, because the plugin "Adds no tools of its own" and "These are the same tools Tray Headless MCP exposes." So the crowding question is answered by how many servers you decided to stand up, and by which tools a person switched off, rather than by what the current job needs.

An agent that guesses at platform behaviour produces plausible nonsense.

59 · The documentation as a corpus the AI consults before acting

The scenario

Kentmere College: a waitlist branch added mid-enrollment, 900 enrollments an hour riding on it

Kentmere Community College in Ohio enrolls 11,400 students through a two-week window every August, and its student-information integrations are maintained by a single registrar's-office analyst, Dana Ruiz. On day two of the window she asks the AI to add a waitlist branch, which requires knowing exactly how the platform treats a scheduled trigger that fires while a run is still in flight. A confident guess about platform behaviour, applied at 900 enrollments an hour, is not the kind of thing she gets to discover quietly.

Dana asks how a scheduled trigger behaves while a run is still in flight. The AI queries the documentation corpus as a step in the procedure, answers from what is documented, and builds the waitlist branch on that. Or she searches the same corpus herself. Either way the branch rests on the platform's behaviour today, not on a guess.

Grounding on Tray is genuine and should be said before anything else. They publish a machine-readable corpus of their whole documentation set, 184 platform pages, 60 developer pages, 10 help pages and the release notes, all fetchable as clean markdown. The plugin also ships reference skills whose job is exactly this: tray-connectors carries connector names and versions, the property type-wrapper format and common jsonpath shapes, and tray-gotchas is a "Debugging guide for known edge cases and tricky surfaces." What is not published is a documentation lookup the platform answers while the agent is working. The corpus is something the client fetches, the skills are Tray-authored files that ship with the plugin, and for CDK work the reference is a file the developer downloads and keeps current: "The TRAY_CDK_GUIDE.md file is versioned alongside the CDK documentation." Tray does build run-time docs tools, which is the fair way to state this: their Helix CLI ships a tray_get_documentation tool. The published Headless tool list is workflows, projects, connectors, authentication, validation, run and debug. Currency is therefore the reader's problem, and it is checkable today. The Tray Headless product page still answers "What are the six built-in skills for Claude Code and Codex?" with a list including set-workspace, which the shipped plugin removed. An agent grounding itself on the corpus reads whatever the page currently says.

/docs · docs_chat

Agents silently working around platform bugs means the bugs never get fixed.

60 · A toolchain that reports its own defects

The scenario

Tessellate Mutual: silent AI workarounds becoming next hail season's undocumented 2am problem

Tessellate Mutual, a Kansas crop insurer, pushes 14,000 hail claims through its adjuster platform in the six weeks after storm season, and a two-person automation team rebuilds the intake flow every spring. When the AI hits something in the platform layer that behaves differently than documented, the cheap move is to route around it and keep shipping, and that detour becomes permanent, undocumented, and somebody's 2am problem next hail season. Claims supervisor Marla Boyd has already inherited three such detours and cannot tell which were deliberate.

The AI files the defect itself: a structured report to engineering, autonomously, instead of routing around it and shipping. Or Marla files one from the same session. Either way the detour becomes a record with the defect attached, not an undocumented workaround somebody inherits. The tools get better because the agent using them is also their reviewer.

When the agent hits something in the platform rather than in the integration, the route Tray documents is a person writing it up and assembling the evidence by hand: the server URL, the tool name, the error text and the execution IDs pulled out of the workflow logs. Support ticket creation has its own documented page and its own human steps. For their build copilot the published channel is product feedback rather than a defect record: "Don't hesitate to share your thoughts using the in-app feedback form or reach out to us directly on Slack", and Tray describes the loop as "analyzing user feedback data via the thumbs up and thumbs down responses." Both are useful. Neither produces a tracked item an operator can point at next week. The knowledge that flows the other way is Tray's to author. tray-patterns and tray-gotchas are Tray-written reference files shipped in their public plugin repository, at v2.0.1 on 2026-08-19, which is a real institutional memory and an actively maintained one. They install into your own plugin directory, so an agent can append a quirk to them locally; what Tray publishes is the repository the shipped versions come from, so carrying a local note through a plugin update is your team's housekeeping rather than a platform behaviour. And no tool in the published surface files the platform defect itself: the documented channels are the in-app thumbs, Slack and the support portal.

/report-mcp-issue