Deciding What to Accept Automatically

The reframe

Acceptance Is a Commitment, Not a Triage Step

It is tempting to read /approval as "route this to my team". It is not. Accepting a collaboration request tells the partner that an engineer is engaged on their problem, and it satisfies the response SLA at the same moment. Those two effects pull in opposite directions, and that tension is the whole subject of this page.

So automatic acceptance buys guaranteed SLA compliance and spends credibility. If your rule accepts something nobody is going to work, the clock stops and the partner waits — which is a worse outcome for them than an honest breach, because a breach is visible and a false acceptance is not.

The spectrum

Four Postures, All Shipping Today

Implementations

How Each Connector Actually Does It

Zendesk: A Setting for Everything, a Trigger for Conditions

Since app v1.0.69 there are two paths, split by policy. Accepting everything is a built-in app setting — Auto-accept inbound requests, off by default — that accepts each inbound case the moment its ticket is created, with your ticket number as the case reference. It is deliberately unconditional, and toggling it takes effect only after a bundle redeploy. Accepting conditionally stays with a Zendesk trigger on the TSANet Action field, which rides the optional field-actions feature: fire on ticket creation, condition on the inbound tag, action sets TSANet Action to Accept. Both run server-side, so no agent needs to be logged in, and both are verified end to end — the partner sees the case accepted roughly fifteen seconds after submitting it.

Crucially, trigger conditions are the scoping mechanism. A condition on the partner field turns "accept everything" into "accept everything from this partner" — which moves you along the spectrum without writing anything. Cases that do not match simply stay open for normal triage.

Salesforce: Verify, Then Accept — Or Ask

The shipped template, Trigger Handler (Asset), is the most opinionated of the four. It ships deactivated, for you to clone and activate. It fires on TSANet Case creation where direction is inbound and no local case is linked:

Get Asset                            as shipped, Asset Name = the case's email field
  └─ no match  → send the partner an information request
  └─ match     → continue
Create the Salesforce Case
Link it to the TSANet Case
Approve the collaboration request
Notify the case owner

Asking on no match is the entitlement check in its softer form. A partner escalating about something you have no record of does not become a case your team owns. It gets a question back straight away instead of a silent wait.

Dynamics: Attach to Work That Already Exists

Auto-routing is a feature toggle rather than a flow to activate, and it solves a different problem: not "should we take this" but "where does this belong". It searches for an existing case by the partner's case number, falls back to a customer-name lookup, and on a match creates and relates the local case before approving.

Matching on the partner's own case number first is what makes re-collaboration on a continuing issue attach to the same case rather than opening a duplicate. That is worth having even if you never intend to auto-accept.

Fin / Intercom: Draft Automatically, Commit Deliberately

The gateway-class connector takes the opposite position and states the reasoning explicitly: accepting, declining and requesting information are contractual commitments to another vendor, made under a service-level clock. Automation composes the answer; a person makes the commitment.

There is a second reason specific to AI-assisted flows. Partner escalations carry end-customer logs and text pasted in verbatim — untrusted content arriving at a system that would then reply under your company's name. Keeping a human on the commitment is also a containment boundary.

Designing yours

Building a Rule That Asserts Something True

The Salesforce flow is the useful template even on other platforms, because its shape generalises: resolve an identifier, branch on whether you found it, and decide what no match means. What varies is the identifier.

Two design rules worth adopting whichever identifier you pick:

• Decide what "no match" means before you build. There are three answers. Rejecting is a real answer, and kinder than silence, but only if your matching is good enough that a rejection is usually correct. Asking for information, which is what the Salesforce template does, is safer when the partner may just have quoted a different identifier. Leaving the case open for a human is the fallback when you are unsure. Rejecting wrongly is worse than not automating.
• Start scoped, then widen. One partner, or one product line, with everything else falling through to normal triage. Every connector that automates acceptance supports a conditional form, and it converts a policy question into an observation: run it narrow for a month and count how often the rule was right.

Failure modes

What Goes Wrong, in the Order You Will Meet It

• The silent accept. A rule accepts a case that lands in a queue nobody watches. The clock is off, so nothing escalates, and the partner waits on an engineer who was never assigned. This is the failure that auto-accept exists to prevent and the one it most often causes.
• The confident reject. Matching runs against stale reference data and declines a request that was perfectly valid. The partner has to re-submit, and now believes your integration is unreliable. Audit your rejections before you trust them — they are the ones nobody complains about internally.
• Accepted, but nothing was created. The approval call succeeds and the local case creation fails after it. The partner sees acceptance; you have no record. Order the steps so the local record exists first where the platform allows it, and treat a post-acceptance failure as an alert rather than a log line.
• Status divergence. Your side auto-accepts and shows a case as owned, while the partner's connector shows only "Accepted" with no engineer name they recognise. Both are technically right. Agree with your frequent partners what acceptance means operationally, because the API does not define it for you.
• The rule outliving its reason. A scoped trigger added for one partner during one incident is still accepting everything from them two years later. Anything that commits automatically deserves a review date.