23.1 Integrated Scenario Practice: Designing an End-to-End Solution

23.1 Integrated Scenario Practice: Designing an End-to-End Solution

Core Concept: Professional-level questions often describe a business scenario and ask for the best design across several topics at once. This section works through one integrated case, the kind of reasoning the exam expects, and connects each decision to the topic behind it.

---

The Scenario

A logistics company receives supplier invoices by email in a shared Microsoft 365 mailbox, about 3,000 per month, with peaks at month-end. Requirements:

1. Start processing soon after an invoice arrives.
2. Extract invoice data, check it against purchase orders in the ERP (desktop client, no API), and post approved invoices.
3. Invoices above 25,000 need a manager's approval with the option to change the approved amount.
4. Keep an auditable record of every invoice and its status.
5. Handle ERP outages without losing invoices; retry technical failures but never retry data problems.
6. Finance users ask questions such as "Why was invoice 4471 rejected?" in plain language.
7. Promote the solution from test to production without editing workflows.

---

A Reference Design

---

Why Not the Alternatives?

• A time trigger every 5 minutes would start empty jobs; the event trigger starts only when mail arrives.
• Keeping invoice data only in queue items loses a searchable history after processing; Data Fabric keeps the record, and the queue carries the Id. Queue items also have a Specific Data limit of 256,000 characters.
• Retrying everything in the framework with MaxRetryNumber greater than 0 while also using queue Auto Retry would multiply attempts; with queues, the framework value must be 0.
• A form task would work for simple approval, but the managers also need supplier history lookups during review, which an action app can provide through Integration Service or Data Fabric.
• Waiting for approval inside the performer would hold a robot; the coordinator suspends instead.

---

Walking Through One Invoice

1. 09:02 An email with INV-4471.pdf arrives. Within the polling interval, the event trigger starts the dispatcher.
2. The dispatcher saves the PDF to a new Invoice record (Upload File to Record Field), sets Status "Received", and adds a queue item with the record Id and Reference INV-4471.
3. The queue trigger starts a performer. Get Transaction Item returns the item; the performer reads the record, extracts the data, and finds no matching purchase order.
4. It throws a BusinessRuleException "No PO found". SetTransactionStatus marks the item Failed (Business), and the Invoice record Status becomes "Rejected - No PO".
5. A finance user asks Autopilot "Why was invoice 4471 rejected?". The automation reads the record and returns "Rejected: no purchase order found for supplier ACME."

For an amount over 25,000, the performer instead sets Status "Awaiting approval", and the coordinator's app task handles the approval before posting.

---

Practice Questions for This Scenario

Use the design above to reason about the questions below. For each, identify the topic first, then the rule that decides the answer.

• Which queue setting makes system exceptions retry automatically? (Auto Retry with Max # of retries; framework MaxRetryNumber 0.)
• What happens to an item whose robot crashed mid-processing? (It stays In Progress and becomes Abandoned after about 24 hours, then is retried only if abandoned items retry is enabled.)
• How does the approval step avoid blocking a robot? (Wait for App Task and Resume suspends the coordinator job.)
• How do test and production use different mailboxes? (Package Requirements select the connection per folder.)