Arabic RTL invoice portal from Zoho Books via Zapier
Build a shareable Arabic RTL invoice link from Zoho Books via Zapier. Add social icons, paid status, and due/overdue day counts with a platform decision tree.
Power Automate email trigger not firing: invoice workflow checklist
Power Automate email trigger not firing? Use this checklist to fix shared mailbox folders, permissions, filters, and SharePoint invoice dedup so intake won’t stop.
TABLE OF CONTENTS
If your Power Automate email trigger stops firing, your workflow often looks “fine” in the designer—but nothing moves downstream. The fastest fix is to treat it like an ops incident: verify the mailbox trigger, confirm the folder and permissions, then harden the SharePoint side so duplicates don’t pile up while the trigger is down.
What “not firing” usually means (and why it’s risky)
When an email-triggered flow doesn’t fire, you don’t just miss one automation run—you usually miss all of them until someone notices. For invoice intake workflows, that can quietly create:
- Missing invoices (they arrived, but never got processed)
- Duplicate rows (someone re-runs imports or re-sends emails)
- Partial records (some steps ran manually, others didn’t)
That’s why the right fix is a checklist you can run every time.
Quick triage checklist (10 minutes)
- Confirm you’re using the correct trigger
- If the mailbox is shared, confirm you’re using a shared mailbox trigger (not a personal mailbox trigger).
- Confirm the connection/account still has access to the mailbox.
- Confirm the trigger’s folder setting is valid
- If the trigger is scoped to a specific folder, re-select the folder in the trigger configuration (don’t assume the old selection is still valid).
- If you’re seeing “not found” behavior, it can be a folder-ID mismatch or a permissions mismatch.
- Confirm the trigger’s filter logic is matching real emails
- Subject filtering is fragile when humans forward or reply. If your workflow depends on forwarded messages, verify your filter doesn’t accidentally exclude them.
- If you rely on exact subject matches, switch to a safer “contains” strategy for the stable part of the subject.
- Confirm you can retrieve the email you think should trigger
- If your search step can’t find the email by subject, assume the filter inputs differ from what you expect (punctuation, prefixes, forward markers, etc.).
Hardening checklist for shared mailbox email triggers
Email triggers tend to fail in predictable ways in Microsoft 365 environments. If you’re using a shared mailbox for operational intake (invoices, onboarding, approvals), harden these points:
1) Make folder selection resilient
If a flow is watching a folder instead of the inbox, treat the folder as an “API dependency.”
- Re-select the folder in the trigger UI after changes to mailbox structure.
- Avoid renaming/moving watched folders without a planned update.
- Document the watched folder path as part of your runbook.
2) Validate shared mailbox permissions (not just “it used to work”)
Shared mailbox automations depend on:
- The connection account’s mailbox access rights
- The flow connection still being valid (tokens can expire, licensing can change)
- The folder permission model being consistent with how the connector reads mail
If you’re troubleshooting a flow that ran last week but not today, assume permissions or folder identity changed.
3) Decide what to do with forwarded email
Forwarding changes email metadata in ways that can break subject-based triggers.
If you can control the process, consider:
- Having the sender CC the shared mailbox so the message lands “normally”
- Using a rule to route messages into a dedicated folder
- Using a stable keyword prefix in the subject line
4) Add a dead-man switch (so it can’t fail silently)
Add a lightweight monitoring step:
- If no qualifying emails were processed in X days, send an alert
- Or write a daily “health check” row to a tracker (then alert if missing)
This turns “silent failure” into a visible incident.
SharePoint invoice dedup: clean the backlog safely
When the email trigger fails, the SharePoint side often accumulates duplicate rows because someone tries to “catch up” with manual imports or tests.
If invoices are landing in a SharePoint list or report table, dedupe in this order:
Step 1: Add “created” and “modified” timestamps to your view
To diagnose duplication, you need to see when items were created and last modified.
- Add Created
- Add Modified
- Group or sort by Created to spot bursts (manual tests/imports often create duplicates in batches)
Step 2: Decide what makes an invoice row unique
Pick a stable uniqueness key that survives re-sends.
Examples:
- Invoice number + vendor + invoice date
- Payment/transaction ID + amount + booking date
- Placement/itinerary ID + transaction type + purchase date
If you don’t define this, dedup becomes subjective and unsafe.
Step 3: Delete duplicates only after you confirm the records are truly duplicates
In SharePoint lists, list items are database records—not just “rows in a spreadsheet.”
That means you should:
- Validate the unique key
- Confirm which row is the “keeper” (usually the first-created or most-complete)
- Remove only confirmed duplicates
Step 4: Prevent duplicates going forward
After cleanup, add one of these safeguards:
- A flow that checks for an existing row with the same unique key before creating a new item
- A staging list: email intake writes to staging, then a second flow promotes to the main list after dedup validation
- A “processed” marker (and downstream steps only run once per unique key)
If your invoices live in SharePoint, treat it as part of your automation system—not just a file dump. The cleanest setups we see keep SharePoint as the system of record and run all state changes through the flow, so there's one place to monitor and one place to debug.
Putting it together: the ops playbook
Use this sequence whenever Power Automate email triggers stop firing:
- Prove the email trigger can see the mailbox and folder
- Prove your subject/filter logic matches real emails
- Add monitoring so the failure can’t hide
- Clean up any SharePoint backlog (dedupe with timestamps + unique keys)
- Add a “duplicate prevention” guardrail before turning the workflow back on
When to bring in help
If this workflow is business-critical, the goal shouldn’t be “make it run again.” The goal should be:
- deterministic trigger conditions
- clear folder + permissions assumptions
- dedupe-safe data writes
- monitoring and alerting
If your Power Automate email trigger is business-critical and you've hit the wall on this, book a ZoomFlow session. One of our consultants can walk through your mailbox setup, trigger config, and SharePoint dedup logic live—and ship the hardened version before the call ends.
Related Posts
They Were Re-Entering Every Job Twice. Two Zaps Fixed It.
A US process-server firm re-entered every job into three systems by hand. Two Zaps fixed it: ServManager to QuickBooks invoices and bills, automatically.
From Spreadsheet Chaos to 24/7 Operations: How a Language Access Nonprofit Built a System Their Linguist Network Could Actually Use
See how a language access nonprofit replaced spreadsheets with an Airtable portal and automated invoicing — recovering 150+ staff hours per year.
