Deciding what to accept automatically — TSANet Connect Developer Hub

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.

Accepting does this	Which means
Sets `responded` to true	The platform stops tracking `respondBy`. Your SLA obligation is met — the clock is off.
Records an engineer against the case	The partner sees a named contact and a case number, and reasonably expects work to be happening.
Moves the case out of OPEN	Reject and Request-information are no longer offered by the shipped connectors once a case is accepted. The triage decision has been made. (Connector behaviour — the API page does not state this rule itself.)

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 question is therefore not "should we automate acceptance". It is "what can we assert automatically that is actually true". A rule that can verify entitlement is asserting something. A rule that accepts everything is asserting nothing except that the clock should stop.

The spectrum

Four postures, all shipping today

Accept everything

Zendesk — app setting

Every inbound case is accepted the moment it arrives. No condition, no lookup, no check that the request is one you can act on. Ships as a built-in setting, off by default.

Buys: the SLA can never be breached. Spends: every case is a promise, including the ones that turn out not to be yours.

Accept what matches existing work

Dynamics — auto-routing

Look for a case that already exists for the partner's case number; fall back to the customer name. On a match, create and relate the local case and accept.

Buys: re-collaboration on a known issue attaches to the right place instead of opening a duplicate. Spends: says nothing about entitlement.

Accept what you can verify

Salesforce — asset match

Resolve the serial number to an asset you actually have a record of. On a match, create the case and accept. On no match, reject.

Buys: acceptance means something checkable. Spends: needs clean asset data, and rejects legitimate requests when that data is stale.

Never accept automatically

Fin / Intercom — guardrail

Automation drafts and proposes; a person accepts, declines or asks for more information. The commitment stays with a human even when the answer is machine-generated.

Buys: no promise is made that nobody chose to make. Spends: the SLA clock runs until someone acts.

The two risks trade directly against each other, and no posture removes both. Which one you would rather carry is a business decision about how much a promise to a partner is worth relative to a breached acknowledgment clock.

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.

The published guide is honest about the cost: auto-accept commits you instantly, and the triage options are skipped for auto-accepted cases. If some cases should still be looked at first, use the trigger path and put those conditions in the trigger. Setup guide →

Salesforce: verify, then accept — or reject

The shipped flow is the most opinionated of the four, and the only one that will say no. It fires on TSANet Case creation where no local case is linked, direction is inbound, and a serial number is present:

Get Asset by serial number
  └─ no match  → reject the collaboration request
  └─ match     → continue
Get Contact by customer email        (enrichment, optional)
Create the Salesforce Case           asset, contact, subject, description
Update the TSANet Case               attach the new Case Id
Approve the collaboration request    with engineer details
Notify the case owner

Rejecting on no asset match is the entitlement check. A partner escalating about hardware you have no record of does not become a case your team has to triage — and the partner finds out immediately rather than after 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 be willing to say no. What varies is the identifier.

Match on	Asserts	Fails when
Asset or serial number	We support this specific thing	Asset records are stale or the partner quotes a different identifier
Entitlement or contract	This customer is covered right now	Coverage lives in a system the connector cannot reach
Partner identity	We have an arrangement with this company	Says nothing about the specific request
Existing case number	We are already working this issue	First contact on a new issue never matches
Product or component	This is a thing our team owns	Field is free text and partners fill it inconsistently

Two design rules worth adopting whichever identifier you pick:

Decide what "no match" means before you build. Rejecting is a real answer and it is kinder than silence — but only if your matching is good enough that a rejection is usually correct. If it is not, leave unmatched cases open for a human instead. 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.

If you are unsure where to start: turn on match-to-existing-work routing, which reduces duplicates without asserting anything you cannot back, and leave acceptance manual until you have a matching rule you would defend to a partner.