DA10: Capstone: three automations for Sharma Textiles

Why each option is right or wrong

• “Build each project separately with its own copy” (Incorrect): Three copies drift apart: a fix in one is easily missed in the others.
• “Skip cleaning for the router, which only handles emails” (Incorrect): The router links emails to known contacts, so it benefits from clean data too.
• “Leave alerts until after the demo” (Incorrect): Alerts are part of what makes the projects dependable; the demo should show them.
• “Build shared parts first, then the projects” is correct.

  One tested cleaning step and one error workflow, used by all three projects, means a single fix applies everywhere and the projects behave consistently.

  • n8n: call a shared sub-workflow with Execute Workflow.
  • Test: the shared parts with pinned data first.

📖 Revise: Lesson 1: Planning the capstone

Why each option is right or wrong

• “Straight after the webhook arrives” (Incorrect): If a later step fails, a retry would be skipped as a duplicate, leaving work unfinished.
• “Before the signature check” (Incorrect): Fake events would then be recorded as processed payments.
• “Between creating the invoice and updating the CRM” (Incorrect): A CRM failure would leave the payment marked done with the CRM not updated.
• “After every step has succeeded” is correct.

  Recording it last means a failed run can be retried to finish its remaining steps, while a complete run stops future repeats. The invoice step's own check prevents a second invoice on retry.

  • Test: fail the CRM step, then retry.
  • Pattern: idempotent steps plus a final record.

📖 Revise: Lesson 2: Project 1: the payment workflow

Why each option is right or wrong

• “Accept it; the alert still says what failed” (Incorrect): Without the order ID, the person can't tell which customer is affected.
• “Remove the 401 test from the acceptance list” (Incorrect): Removing a failing test hides a real gap from the client.
• “Add the order ID by hand when the alert comes” (Incorrect): That depends on someone remembering, and slows the fix.
• “Fix the template, then rerun all ten tests” is correct.

  The alert read the order ID from the wrong node. After fixing it, rerunning every test (not just the failed one) confirms that the change didn't break anything else.

  • Record: the first result and the fix.
  • Rubric area: Reliable.

📖 Revise: Lesson 2: Project 1: the payment workflow

Why each option is right or wrong

• “Ask customers to write in English only” (Incorrect): That's unfriendly, and many customers won't follow it.
• “Route everything unclear to Orders by default” (Incorrect): Unclear emails could be returns or accounts; a wrong default misroutes them silently.
• “Replace the keywords with AI and remove the fallback” (Incorrect): AI can help, but removing the person for unclear cases leads to silent misroutes.
• “Add Hinglish phrases and test them” is correct.

  Customers write the way they speak. Adding phrases such as "order nahi aaya" to the Orders keywords, found through the weekly review of corrections, and testing a set of mixed-language emails improves routing for real customers.

  • Keep: the fallback to a person for anything unclear.
  • Measure: correct-routing share before and after.

📖 Revise: Lesson 3: Project 2: the inbox router

Why each option is right or wrong

• “That the AI service is the most popular one” (Incorrect): Popularity doesn't answer what happens to the client's customer data.
• “That the AI is right more often than the keyword table” (Incorrect): Accuracy matters, but data permission comes first.
• “That the emails are short enough” (Incorrect): Length is a detail; data permission is the first question.
• “The client's data rules and the service's data handling” is correct.

  Emails contain personal data. Before sending them to an outside AI service, check that the client allows it and what the service stores or uses. If allowed, keep a person in the loop for low-confidence results.

  • Data map: add the AI service as a system.
  • Next: the AI/ML path covers this in depth.

📖 Revise: Lesson 3: Project 2: the inbox router

Why each option is right or wrong

• “Declare the router finished; 28 of 30 is good enough” (Incorrect): The two misses show specific gaps that are easy to fix.
• “Remove the fallback, since most emails are routed well” (Incorrect): The fallback is why no email went unassigned; removing it creates silent misses.
• “Rewrite the router using a different platform” (Incorrect): The design works; it needs small improvements, not a rebuild.
• “Fix the misses; review corrections weekly” is correct.

  Each miss points to a missing phrase. Fixing them, and reviewing the person's corrections weekly, keeps improving the keyword table as customers' wording changes.

  • Example: "send back", "wrong colour" → Returns.
  • Track: correct-routing share each week.

📖 Revise: Lesson 3: Project 2: the inbox router

Why each option is right or wrong

• “Raise the limit to 30% permanently” (Incorrect): Later runs should change far fewer; a high limit would miss a real bug.
• “Run it anyway, since the first run is expected to be large” (Incorrect): Expected or not, the large change is exactly the case the limit is for.
• “Split it into three smaller runs to stay under the limit” (Incorrect): That gets round the safety check instead of using it.
• “Pause for a person to review the report and approve” is correct.

  The limit exists so that large changes are checked. The first clean-up is expected to be large, so a person reviews the report and approves it. Later runs, with small changes, go through automatically.

  • Before live: two dry runs and a backup.
  • Following week: only 6 contacts changed.

📖 Revise: Lesson 4: Project 3: the weekly CRM tidy-up

Why each option is right or wrong

• “A rule to rename the field back” (Incorrect): The next change elsewhere would cause the same damage.
• “A slower schedule, such as monthly” (Incorrect): Running less often doesn't stop a wrong run.
• “Manual merging only from now on” (Incorrect): That brings back the manual work the automation was for.
• “A sanity check, a dry run and a change limit” is correct.

  A check that stops the run when a key field is empty for most contacts catches this kind of bug. Dry runs show changes before they happen, and the change limit pauses large changes for approval.

  • Keep: the backup export before each live run.
  • Then: two dry runs before going live again.

📖 Revise: Lesson 4: Project 3: the weekly CRM tidy-up

Why each option is right or wrong

• “Several successful runs, to show it's dependable” (Incorrect): Successes don't show how failures are handled.
• “A slide listing the error types it handles” (Incorrect): A slide describes it; a live run proves it.
• “An explanation that failures are rare” (Incorrect): Rare failures still happen, and the business needs to know what to do.
• “A forced 401, the alert, the runbook fix and a retry” is correct.

  Showing a real failure, the alert reaching its owner, the fix from the runbook and a clean retry proves the part the business depends on most. It also shows the handover works.

  • Then: show the run log entry.
  • Rubric areas: Reliable and Handover.

📖 Revise: Lesson 5: Demo, self-review and case study

Why each option is right or wrong

• “Met; everything connects and works” (Incorrect): Working isn't the whole standard: least access is part of "Connected".
• “Not yet, and remove the CRM from the capstone” (Incorrect): The connection works; it needs a small fix, not removal.
• “Leave the area blank” (Incorrect): A blank area hides what you know and gives the reviewer nothing to go on.
• “Partly, with evidence and the fix you'll make” is correct.

  An honest "partly" with a clear plan (reduce the scopes to the three the workflows use) is more useful than a vague "met". It also points to a quick fix before the demo.

  • Evidence: the scopes list in the credentials file.
  • After fixing: update the rating to met.

📖 Revise: Lesson 5: Demo, self-review and case study