DA2: n8n in depth

Why each option is right or wrong

• “n8n Cloud, since it removes the need for any updates” (Incorrect): Cloud does remove upkeep, but the data would sit in the provider's region, not a server the clinic chose.
• “Any set-up, because n8n doesn't store personal data” (Incorrect): Executions can keep the data each node processed, including names and phones.
• “A laptop running n8n at the reception desk” (Incorrect): A laptop can be switched off, lost or stolen; a proper server is safer and stays online.
• “Self-hosted n8n on a server in India” is correct.

  Self-hosting lets the clinic choose where the data lives, which is their main concern. They also have someone to apply updates and backups, which self-hosting needs. Add HTTPS, a strong owner password and a safely stored encryption key.

  • Trade-off: control over data in exchange for upkeep.
  • Agree up front: who updates, who backs up, and how often.

📖 Revise: Lesson 1: Cloud or self-hosted

Why each option is right or wrong

• “The file is damaged and should be exported again” (Incorrect): The file is fine; credentials are left out by design.
• “Google Sheets nodes can only run in the original account” (Incorrect): Any account with access to the sheet can be used.
• “Your n8n version is too old to read credentials” (Incorrect): Exports leave credentials out, whatever the version.
• “Credentials aren't exported, so you add your own” is correct.

  n8n stores credentials separately and encrypted, and exported workflows leave them out on purpose. This keeps secrets from travelling in files. You create your own credential and select it on the node.

  • Good habit: name credentials by purpose, like "Sharma Sheets".
  • Check exports: no keys should appear in the JSON.

📖 Revise: Lesson 2: Nodes, credentials and expressions

Why each option is right or wrong

• “Running the workflow more often” (Incorrect): Running more often sends the same values down the same broken path.
• “Removing the Switch node and emailing every order to accounts” (Incorrect): Accounts would be flooded with orders they don't need.
• “Converting all order types to numbers” (Incorrect): Numbers can be mistyped too; the real gap is the missing fallback.
• “A fallback output that alerts a person” is correct.

  Without a fallback, items that match no rule simply stop, and nobody is told. A fallback output catches unexpected values and alerts the manager, so a change like a capital letter is noticed quickly. Making the comparison case-insensitive fixes this particular case.

  • Name nodes clearly: "Order type" rather than "Switch1".
  • Test: send an unexpected value on purpose.

📖 Revise: Lesson 3: Branching with IF and Switch

Why each option is right or wrong

• “The Merge node is faulty; use a Code node instead” (Incorrect): The node did what it was asked; the match field was the problem.
• “Six orders were placed twice; delete the duplicates” (Incorrect): The extra items come from the CRM side, not from duplicate orders.
• “Merge mode should be "append" so the counts add up” (Incorrect): Append just stacks the lists (35 + 1,200 items); it doesn't join orders to contacts.
• “Duplicate names matched twice; match on phone instead” is correct.

  Merging by matching fields joins every pair that shares the value. If two contacts are called "Rahul Kumar", each of their orders matches both. A unique field such as phone avoids this, and checking that the item count is still 35 after the merge catches problems early.

  • Rule: match on a unique field.
  • Guard: stop the workflow if counts don't match.

📖 Revise: Lesson 4: Merging and looping over items

Why each option is right or wrong

• “Rewrite the workflow from scratch in another tool” (Incorrect): The message points to a sharing problem, not a design one.
• “Increase the server's memory” (Incorrect): Memory doesn't affect permission errors.
• “Change the schedule from 8 am to 9 am” (Incorrect): The time isn't the issue; the sheet is no longer shared with the account.
• “Re-share the sheet with n8n's account; retry” is correct.

  A permission error with normal input points to access, not data. Someone has probably removed the account from the sheet's sharing settings. Re-sharing it and retrying the failed execution completes the run without rebuilding anything.

  • Prevent: keep a note of which accounts each workflow needs.
  • Detect: an error workflow alerts you straight away.

📖 Revise: Lesson 5: Reading executions and fixing failed runs

Why each option is right or wrong

• “Ask the shop platform to switch off retries” (Incorrect): Retries are a normal safety feature, so duplicates should be expected.
• “Send messages only once a day in a batch” (Incorrect): Customers want shipping updates promptly, and batches don't stop duplicates.
• “Delete the second execution from the log” (Incorrect): The messages were already sent; deleting the record hides the problem.
• “Reply fast and skip orders already done” is correct.

  The shop resent the webhook because your workflow answered slowly. Replying straight away reduces retries, and checking whether an order ID was already processed makes repeats harmless. Workflows that handle repeats safely are called idempotent.

  • Store: processed order IDs in a sheet or database.
  • Covered more: in DA6, Reliable automations.

📖 Revise: Lesson 5: Reading executions and fixing failed runs

Why each option is right or wrong

• “The Google Sheets API is slow on Mondays” (Incorrect): A delay of exactly five and a half hours points to time zones, not slowness.
• “The schedule node only supports whole hours in UTC” (Incorrect): It supports any time; the zone setting decides which 8 am you get.
• “The container restarts every morning and delays runs” (Incorrect): A restart wouldn't shift every run by exactly 5.5 hours.
• “n8n's time zone is UTC instead of Asia/Kolkata” is correct.

  India is five and a half hours ahead of UTC. If n8n or the workflow uses UTC, "8 am" means 8 am UTC, which is 1:30 pm in India. Setting the time zone to Asia/Kolkata makes schedules run at local times.

  • Self-hosted: set GENERIC_TIMEZONE.
  • Per workflow: the workflow settings can override it.

📖 Revise: Lesson 1: Cloud or self-hosted

Why each option is right or wrong

• “n8n can't compare amounts in rupees” (Incorrect): It can, as long as both values are numbers.
• “The expression needs single braces instead of double” (Incorrect): Double braces are correct for n8n expressions.
• “The IF node rounds large numbers down to zero” (Incorrect): Nothing is rounded; the values are being compared as text.
• “It's compared as text, letter by letter” is correct.

  When both sides are text, comparison goes character by character, and "6" comes after "5", so "600" counts as larger. Convert the field to a number first, or set the IF node's comparison type to number, so 600 is compared as a quantity.

  • Fix: {{ Number($json.amount) > 5000 }}.
  • Prevent: check field types when you first map data.

📖 Revise: Lesson 3: Branching with IF and Switch

Why each option is right or wrong

• “Send all 600 at once and retry the failures” (Incorrect): Most would fail and the retries would hit the limit again.
• “Ask the supplier to remove the limit” (Incorrect): Limits protect their system; you design around them.
• “Merge the 600 updates into one huge request” (Incorrect): The API may not accept bulk requests, and one failure would lose everything.
• “Loop Over Items in batches, with a Wait between them” is correct.

  Sending all 600 at once would break the limit and cause errors. Splitting them into batches, for example 25 at a time with a one-minute wait, keeps within 30 requests a minute. It takes longer, but every update gets through.

  • Watch: the API's error messages about limits (often status 429).
  • Log: which batch failed, so you can resume.

📖 Revise: Lesson 4: Merging and looping over items

Why each option is right or wrong

• “Copy each test order into the code by hand” (Incorrect): Typing data by hand is slow and error-prone.
• “Test only in production with real customers” (Incorrect): That risks real messages and records from test runs.
• “Turn off the webhook node while testing” (Incorrect): Later nodes then receive no data to work with.
• “Pin sample data on the webhook node” is correct.

  Pinning saves one real-looking item on the node, so the later steps receive the same data every time you run the workflow. You build and test the rest without triggering new orders. Unpin it before going live.

  • Use: a realistic sample, including tricky values.
  • Remember: pinned data is for building, not production.

📖 Revise: Lesson 2: Nodes, credentials and expressions