Reference · built on requestOperator by FibricReporting & analysis

Exception Digest

The day's unresolved exceptions across payments, shipping, and support collected into one list, with an owner proposed for each item.

Request accessPricing ↗

About

Exceptions sit in three inboxes and nobody owns the union. This operator builds the union once a day. From the payment processor it reads disputes with status needs_response and their evidence due dates, and refunds that failed. From the shipping system it reads trackers in failure, return_to_sender, or error, and labels voided after shipment. From the help desk it reads tickets with a breached SLA metric and tickets in a named view that have gone unassigned. It checks the work tracker for an existing issue on each item so nothing is listed twice.

Each item gets a proposed owner from the roster you maintain. Approving an item creates the issue and assigns it.

This is a reference listing. It documents what Fibric would read from Exception Digest and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Stripe disputes with status needs_response or warning_needs_response, with evidence_details.due_by and the charge
  • Stripe refunds that reported refund.failed, with the charge and the amount
  • EasyPost trackers whose status is failure, return_to_sender, or error, with the last tracking detail
  • ShipStation shipments voided after their ship date, by voidDate
  • Zendesk ticket metric events of type breach, and tickets in a named view with no assignee
  • Open issues in Jira or Asana that already reference an exception, matched by the item's id
  • The owner roster: which person or team takes which exception type

Proposed actions

  • Target capability: propose the day's digest as one list, each item with its system, id, age, and deadline where one exists
  • Target capability: propose an owner for each item and, on approval, create the issue in Jira or the task in Asana assigned to them
  • Target capability: propose closing a digest item whose source record has since resolved
  • Target capability: propose a roster change when an exception type has no owner and items of that type recur

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Stripe, EasyPost, and Zendesk into Jira

    Disputes needing a response, failed deliveries, and breached tickets are listed each morning. Approving an item creates a Jira issue with write:jira-work, assigned to the roster owner, linked back to the source record.

    With Stripe, EasyPost, Zendesk, Jira

  • Voided labels as exceptions

    Labels voided in ShipStation after the ship date are listed beside the order, so the re-ship or refund decision has an owner in Asana by the end of the day.

    With ShipStation, Asana

  • Close what resolved

    When a dispute moves to under_review or a tracker reaches delivered, the digest proposes closing the item and the linked issue, with the source status recorded.

    With Stripe, EasyPost, Jira

  • Breaches from a Zendesk view

    A named view of unassigned tickets and breach metric events are combined so an unowned breach is one item, never two.

    With Zendesk, Linear

Requirements

  • A payments connector exposing disputes and refunds: Stripe, Adyen, or PayPal
  • A shipping connector with tracker or shipment status: EasyPost, ShipStation, or AfterShip
  • A support connector with SLA metric events or views: Zendesk, Kustomer, or Freshdesk
  • A work tracker where owned items become issues: Jira, Asana, or Linear
  • An owner roster by exception type, kept by you
Authentication
Read on disputes and refunds, tracker read on the shipping connector, ticket and metric-event read on the help desk, and issue create scope on the work tracker.

Limits

  • Zendesk incremental ticket metric events can be read by admins only. An agent token cannot supply the breach list.
  • A dispute's due_by is set by the card network through Stripe. The digest shows it; it does not extend it.
  • EasyPost tracker status depends on carrier scans. A package with no scans stays pre_transit and does not appear as an exception.
  • It lists an item once per source id. The same order with a dispute and a failed delivery appears twice, once per system.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Exception Digest ↗

Questions and answers

What do I approve in the digest?
Each item's owner. The digest lists the item, its source record, its age and deadline, and the proposed owner. Approve one, change the owner, or leave it unowned. Only approved items become issues.
What record does the digest leave?
The digest as proposed, the decision on each item, the issue key created and the assignee, and the source status at listing and at close. Unowned items stay in the record and reappear the next day.
Does it act on the exception itself?
No. It never submits dispute evidence, retries a refund, re-ships a package, or replies to a ticket. It lists, proposes an owner, and creates the issue after approval.
Ask about Exception Digest

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy