Unilytic docs 01Unilytic product guideUpdated 19 October 2026

The automated emails you receive and the ones you control

What each report tells you, who receives it, every setting it has, and the quota arithmetic that decides whether it arrives at all — with a picture of each one as it lands.

By Akshat Agrawal10 min read

What the system does

Inventory failures are almost never sudden. A SKU drifts downward for eleven days before it goes out of stock. An Amazon connection breaks and the dashboard simply stops changing, which looks identical to a quiet week. A reimbursement window closes while the claim sits on somebody's list. Every one of these is completely visible to whoever happens to look on the right day, and the entire problem is that nobody does.

Unilytic's automated emails exist to convert those from things you must remember to check into things that interrupt you only when they matter. There are two kinds, and the difference governs everything else in this guide:

Reports you configure. A digest of low stock, excess stock, warehouse throughput or claims still to file. You choose the template, the recipients, the day and the time. Nothing arrives until you make a rule.

Alerts that configure themselves. Your trial is ending, a payment failed, the Amazon sync has been dead for three days. These do not wait for a rule because the thing they report is that something is already broken. They go to owners and admins, and they cannot be switched off.

Everything is set up at Settings → Automated emails.

Which ones you control

Open the settings page and you will count seven rows — six reports you can create plus one default. Some of the emails you receive are not on that page, and that is deliberate rather than a gap: the ones reporting that something has broken do not wait for you to switch them on. Knowing which group an email belongs to saves you hunting for a switch that does not exist.

Scroll the table sideways for the remaining columns.

The emails you can receive, by how much control you have over each
Group	How many	Who receives it	Can you turn it off?
Scheduled reports	6	the rule's recipients	Yes — that is the whole point of them
Fee mismatch alert	1	the rule's recipients	Yes, if it is visible to your workspace at all
Warehouse delete request	1	warehouse managers, otherwise owners and admins	Only by disabling its rule — see the trap below
Always-on alerts	9	every owner and admin	No

So eight can be configured, and seven of those are visible to a typical workspace. The always-on group arrives whether you plan for it or not, and it is documented below anyway — an email landing in your team's inbox is worth understanding even when you cannot stop it.

What they look like

They are sent by Unilytic, not by Amazon or Seller Central, and they are not Amazon notifications — the stock, returns and claim figures in them are Unilytic's reading of your Amazon data. They are all built from the same branded shell, so they are recognisable in a crowded inbox: the logo, one accent bar, a white card, the numbers as a plain table, and a footer that tells you why you received it. The coloured header changes tone with the news — neutral for a report, amber when something needs doing, red when a date has passed or a payment failed.

The Unilytic low stock digest email: an amber header reading 4 to restock, then a table of four SKUs with quantity and days of cover. — The low stock digest, rendered by the real template rather than mocked up. The header counts the SKUs needing action, the subhead states the threshold the list was built from — 14 days here — and the footer says which workspace it was sent to and links to the settings page.

The footer line matters more than it looks. Team reports say which workspace they went to, and each recipient's copy carries their own “Stop receiving this email” link, so anyone on a rule can take themselves off it without asking an admin. Billing and trial notices deliberately carry no opt-out line, because there is nothing to opt out of.

The emails, in detail

Click any name to open its record — what it tells you, when it fires, who gets it, what it costs against your quota, every setting it has, and what it looks like when it arrives.

Scheduled reports6

You create these. Nothing arrives until a rule exists. All six count against your monthly quota.

Low stock digestlow_stock_digestSKUs below your days-of-cover thresholdScheduled

What it tells you: Every SKU whose remaining cover has fallen under your threshold, with its current units, days of cover and the reason it was flagged. The same arithmetic as the dashboard's needs-attention list.
When it fires: Daily or weekly, at a time you choose.
Who receives it: Whoever the rule lists — up to 25 people, of any role, each of whom must be a current member of the workspace. Anyone who has used the unsubscribe link is skipped.
Can you turn it off: Yes — disable or delete the rule.
Its own settings: None. The threshold is the workspace-wide low_stock_days, default 14 days, set in Organization settings rather than here.
What stops it: Nothing. If no SKU is low it still sends, with an empty table, and still costs quota — so don't switch it on before your first Amazon import has finished.
Quota: Counts, once per recipient.
Slack: Yes.

The low stock digest email: an amber header reading 4 to restock, then a table of four SKUs with quantity and days of cover. — Four SKUs under a 14-day threshold. The header counts what needs action; the last row is a SKU already at zero.

Excess stock digestexcess_stock_digestSKUs sitting above your excess threshold, ranked by coverScheduled

What it tells you: SKUs with more cover than you want capital sitting in, showing units, days of cover and the excess above your threshold. Capped at the worst 25 SKUs per send.
When it fires: Daily or weekly, at a time you choose.
Who receives it: Whoever the rule lists — up to 25 people, of any role, each of whom must be a current member of the workspace. Anyone who has used the unsubscribe link is skipped.
Can you turn it off: Yes.
Its own settings: None. Uses the workspace-wide excess_stock_days, default 45 days.
What stops it: Nothing — an empty digest still sends.
Quota: Counts, once per recipient.
Slack: Yes.

The excess stock digest email: three SKUs with units on hand, days of cover and the excess units above the threshold. — The mirror image of the low stock digest. The excess column is the number of units above your threshold — the part that is capital sitting still.

Weekly growth recapweekly_growth_recapUnits sold, stock on hand, SKUs needing attentionScheduled

What it tells you: Four headline numbers for the week: units sold over the last seven days, total units on hand, total SKUs, and how many need attention. A status check, not a working list.
When it fires: Weekly is the intent; daily is allowed.
Who receives it: Whoever the rule lists — up to 25 people, of any role, each of whom must be a current member of the workspace. Anyone who has used the unsubscribe link is skipped.
Can you turn it off: Yes.
Its own settings: None.
What stops it: Nothing — it sends with zeroes if there is no data.
Quota: Counts, once per recipient.
Slack: Yes.

The weekly growth recap email: four large figures for units sold, units on hand, total SKUs and SKUs needing attention. — Four numbers and no table. This is the one report meant to be read in five seconds rather than worked from.

Warehouse performance (weekly)warehouse_performance_weeklyPer-warehouse units on hand and SKU countScheduled

What it tells you: Each location's sellable units and distinct SKU count, ranked by volume. Warehouses and SKUs you have hidden in your filters are left out.
When it fires: Daily or weekly, at a time you choose.
Who receives it: Whoever the rule lists — up to 25 people, of any role, each of whom must be a current member of the workspace. Anyone who has used the unsubscribe link is skipped.
Can you turn it off: Yes.
Its own settings: None.
What stops it: Nothing — an empty report still sends.
Quota: Counts, once per recipient.
Slack: Yes.

The warehouse performance email: four locations listed with units on hand and distinct SKU count, ranked by volume. — Amazon fulfilment centres and your own depot in one ranking, so you can see where the stock actually is.

Warehouse scan summarywarehouse_scan_summaryReturn intake and the claims you still have not filedScheduled7 settings

What it tells you: Up to four independently switchable sections: damaged units whose claim has not been filed yet, intake counts for the window, a breakdown by claim status, and units newly marked damaged. The most configurable template in the system.
When it fires: Daily or weekly, at a time you choose.
Who receives it: Whoever the rule lists — up to 25 people, of any role, each of whom must be a current member of the workspace. Anyone who has used the unsubscribe link is skipped.
Can you turn it off: Yes.
Its own settings: Pending claims to file — on by default. Pending claim age — at least, or within, 7 days. Intake counts, claim status breakdown and newly damaged units — all off by default. Return type — all, Amazon order, or removal order. Window — 7 days.
What stops it: Emptiness, unlike the digests above: if every section you enabled has nothing in it, the send is skipped entirely and costs you no quota.
Quota: Counts, once per recipient — when it sends at all.
Slack: No. This template has no Slack form. A webhook on this rule is saved and then ignored.

"Pending" here means a damaged unit whose claim status is still untouched. A unit you have already applied for, or that Amazon denied, is not pending — so this report is a list of work not yet started, not work in progress.

The warehouse scan summary email: three pending claims with unit, condition, container and age, followed by intake counts and a damage-rate breakdown. — Pending claims and intake counts both switched on. With only the default section enabled it is just the top table — every section you add makes the email longer, which is the argument for turning on what you will read and nothing else.

Warehouse claim reminderwarehouse_claim_reminderA postponed claim's reimburse-by date approachingScheduled1 setting

What it tells you: Claims Amazon promised to reimburse by a particular date, where that date is near or already past. Shows the unit, the case, the container, the amount filed and days remaining — negative when overdue.
When it fires: Daily or weekly, at a time you choose.
Who receives it: Whoever the rule lists — up to 25 people, of any role, each of whom must be a current member of the workspace. Anyone who has used the unsubscribe link is skipped.
Can you turn it off: Yes.
Its own settings: Remind N days before due — default 3, up to 90. Overdue claims are always included regardless.
What stops it: Emptiness — no claims due, no email, no quota spent.
Quota: Counts, once per recipient.
Slack: No. Email only, like the scan summary.

This and the scan summary sound similar and cover opposite halves of the same job. The scan summary chases claims you have not filed; this one chases claims you filed that Amazon postponed. Running only one leaves a real gap.

The warehouse claim reminder email: two postponed claims with unit, case reference, due date and status, one of them marked two days overdue. — Due in one day, and already two days overdue. Overdue claims stay on the list regardless of your lead-days setting.

Configurable alerts2

Event-driven rather than scheduled, and configurable — but each has a catch about who can see it.

Warehouse delete requestwarehouse_delete_requestedA scanner has asked to delete a received-returns rowOn event

What it tells you: Who asked, which unit and container, and the reason they gave. Return scanners cannot delete records themselves, only request it, so this is the approval step.
When it fires: The moment a scanner requests the deletion.
Who receives it: Owners, admins and warehouse managers only — no other role is eligible, even if you try to add them. Leave recipients empty and it goes to all warehouse managers, or to owners and admins if there are none.
Can you turn it off: Only by disabling the rule. Deleting the rule brings the email back via the default, which is the opposite of what deleting usually means.
Its own settings: Recipients only.
What stops it: A rule that exists and is switched off.
Quota: Exempt — it never counts.
Slack: Yes.

The warehouse delete request email: who asked, the unit barcode, return type, container and the reason they gave. — An approval request, not a report. The reason field is whatever the scanner typed, so it is worth reading before acting.

SKU fee mismatchsku_fee_mismatchAmazon's estimated fees no longer match your referenceOn event

What it tells you: Which SKUs Amazon is now estimating different fees for, the expected versus actual figure per field, and which SKUs it could not check at all.
When it fires: After a fee-estimates sync finds a difference, at most once per day.
Who receives it: Whoever the rule lists — up to 25 people, of any role, each of whom must be a current member of the workspace. Anyone who has used the unsubscribe link is skipped.
Can you turn it off: Yes.
Its own settings: None.
What stops it: No mismatches and nothing missing.
Quota: Counts, once per recipient.
Slack: Yes.

This one is limited to workspaces with listing management enabled. If that is not yours, the template does not appear on the settings page at all — so if you cannot find it, nothing is wrong with your account.

The SKU fee mismatch email: two SKUs where the expected and actual fee differ, plus a count of SKUs checked and skipped. — Expected against actual, per fee type. The counts at the end matter as much as the list — they say how much of your catalogue was checked at all.

Essential alerts9

Always on. They report that something is already broken or that money moved, so they do not wait for a rule. They go to every owner and admin, they ignore your monthly quota, and no setting anywhere switches them off.

Trial ending soontrial_endingYour free trial is about to expire, or just hasAlways on

What it tells you: How long is left and when it expires.
When it fires: At 3 days, 1 day and 0 days remaining — three emails at most, never a daily countdown. A workspace that has never imported any data gets only the last one, on the day the trial ends.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
What stops it: Being on a paid plan, or having no trial — including a workspace whose owner had already used their trial elsewhere.
Quota: Exempt.

Billing failedbilling_failedThe subscription was halted, paused or expiredAlways on

What it tells you: Which status the subscription moved to.
When it fires: On the payment provider's notification, once per status change.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
Quota: Exempt.

Payment receiptpayment_receiptA subscription payment succeededAlways on

What it tells you: Amount, currency, plan, next renewal date and the payment reference.
When it fires: On each successful payment.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
Quota: Exempt.

Amount chargedplan_changedThe subscription was upgraded or downgradedAlways on

What it tells you: Which plan you were on and which you are on now.
When it fires: On an upgrade or downgrade taking effect.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
Quota: Exempt.

Subscription cancelledsubscription_cancelledA subscription was cancelled or reached its endAlways on

What it tells you: Why it ended and on what date.
When it fires: Once, when the subscription reaches a terminal state.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
Quota: Exempt.

New member joinednew_member_joinedSomeone accepted an invitationAlways on

What it tells you: Who joined and with which role.
When it fires: When the invitation is accepted, once per person.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No — despite reading like a team preference, this is classified as essential.
Quota: Exempt.

First Amazon import finishedfirst_sync_completeYour initial import completedAlways on

What it tells you: Which parts of the import succeeded and which did not, so you know whether the dashboard you are about to open is complete.
When it fires: Once per workspace, ever. Not once per sync — once.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
What stops it: An import still in progress, or one where nothing completed.
Quota: Exempt.

Amazon sync stalledsync_stalledNo successful sync for several daysAlways on

What it tells you: How many days since the last success, how many attempts have failed, and which parts are failing.
When it fires: Once the gap reaches three days, then at most once every three days after that — so a long outage does not become a daily alarm.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
What stops it: Switching off the nightly sync, or a dead authorisation — which sends the reconnect alert instead, never both.
Quota: Exempt.

Amazon reconnect requiredamazon_reconnect_requiredAmazon stopped accepting the stored authorisationAlways on

What it tells you: Since when the connection has been refused. The fix is always to reconnect Amazon.
When it fires: Once per episode of a dead authorisation.
Who receives it: Every owner and admin in the workspace, resolved at send time.
Can you turn it off: No. It cannot be made into a rule or switched off.
Quota: Exempt.

Settings that live elsewhere

Two of the most useful reports have no thresholds of their own, which is the single most common source of confusion about this page. The low stock digest and the excess stock digest read your workspace's dashboard settings, not the rule:

Scroll the table sideways for the remaining columns.

Thresholds that govern the digests but are set on another page
Setting	Default	Where it lives	What it changes
Low-stock threshold	14 days of cover	Organization settings	Which SKUs appear in the low stock digest — and in the dashboard's needs-attention list
Excess threshold	45 days of cover	Organization settings	Which SKUs appear in the excess stock digest
Hidden SKUs and warehouses	none	Filter settings	Excluded from the warehouse performance report

These are workspace-wide. Raising the low-stock threshold to suit a long inbound lead time also changes what everyone else sees on the dashboard — you cannot have a stricter threshold for the email than for the app. Change them in Organization settings.

Schedules and timezones

A scheduled rule needs a frequency, a time and a timezone. Daily and weekly are the two frequencies; weekly also takes a day. Three things are worth knowing before you set one:

Minutes must be 00, 15, 30 or 45. The scheduler wakes every fifteen minutes, so those are the only times it can honour. The interface will not let you save 09:10, and that is a feature — a rule set to a minute nobody checks would fire unpredictably or never.

The timezone is per rule, defaulting to the workspace's. A new workspace starts on Asia/Kolkata. Set the workspace default once, then override it on the individual rule if one report belongs to a team in another country.

Nothing fires to the minute. A 09:00 rule goes out during the quarter-hour window beginning 09:00. If a report must be read before a stand-up, schedule it an hour earlier rather than fifteen minutes. A run is only attempted in its own window: if a scheduler tick is missed, that run is not made up afterwards.

Quotas, with the arithmetic

Every plan has a monthly ceiling on configurable emails, and the counting rule is the part that catches people: it counts recipients, not sends. One rule going to four people costs four.

Scroll the table sideways for the remaining columns.

Monthly email allowance by plan, and what it actually buys
Plan	Emails per month	Slack	A daily digest to one person
Free	25	Not available	Runs out around the 25th, every month
Pro	200	Available	Comfortable — about 30 of 200
Business	500	Available	Comfortable

That first row deserves saying in words. A daily report is roughly 30 sends a month. On the Free plan, which allows 25, one daily digest to one person cannot complete a month. It will stop somewhere around the 25th, silently, and resume on the 1st. If you are on Free, run weekly reports — four or five sends a month each — and you can have several.

When the ceiling is reached the send is not queued or delayed; it is skipped, and it leaves no trace — no entry appears in Recent activity, so a rule that has been silently blocked for a week looks exactly like a rule that had nothing to report. The usage card is the only place the cap is visible. The allowance resets at the start of each month, counted in UTC. The always-on alerts never count, so you cannot lose a billing warning to a month of digests.

The check is all-or-nothing for each send. Before a rule sends, Unilytic adds the number of people it is about to email to what you have already used. If that total would pass the cap, the whole send is skipped — it is not trimmed to the allowance you have left. On the Free plan, with 23 of 25 used, a rule with four recipients is skipped entirely even though two emails remain, while a one-recipient rule fired afterwards still goes out. The counter only moves for emails that were actually sent: test sends, failed sends, empty reports that were skipped, and anyone dropped before sending (they left the workspace, or unsubscribed) cost nothing.

The usage card at the top of the settings page shows where you are, turns amber at 80% and red once the cap is reached, when it says new sends will be blocked until next month or you upgrade. It only appears if your plan has a finite allowance.

Slack

Any rule can also post to Slack. Create an incoming webhook in Slack, paste the URL into the rule, and the same report arrives in a channel. Three rules apply:

Slack needs Pro or Business — on Free the field is disabled. The URL must begin with https://hooks.slack.com/. And Slack messages do not count against your email allowance, which makes a channel the cheapest way to give a whole team visibility: one Slack post instead of eight recipients.

One thing I will say plainly

Two templates have no Slack version at all — the warehouse scan summary and the warehouse claim reminder. The field accepts your webhook, saves it without complaint, and then nothing is ever posted to the channel.

That is a gap in my interface, not in your setup. Until it says so on the page, treat those two as email-only.

Who can change what

Scroll the table sideways for the remaining columns.

Access to the automated emails page by role
Role	Can read the page	Can change rules	Can receive emails
Owner	Yes	Yes	Yes, plus every always-on alert
Admin	Yes	Yes	Yes, plus every always-on alert
Member	Yes	No	Yes, if a rule lists them
Warehouse manager	No — cannot open it	No	Yes, if a rule lists them; default recipient of the delete request
Return scanner	No — cannot open it	No	Yes, if a rule lists them

Any member of the workspace can be a recipient, whatever their role. Receiving an email and being able to configure one are separate things: the only requirement for a recipient is current membership. So you can send the scan summary to a return scanner who has no access to anything but the scan screen. The single exception is the delete request, which accepts only owners, admins and warehouse managers — because it is an approval, and the other roles cannot act on it.

Two consequences worth planning around. A plain member can read every rule and the delivery history but change nothing, so you can let people see what is configured without granting them control. And a warehouse manager or scanner can receive reports while having no way to open the page they are configured on — if they want a change, they have to ask an owner or admin.

Recipients must be members of the workspace, and this is re-checked when the email is sent, not just when you save. Someone who leaves the organisation stops receiving reports immediately, with no edit needed — and disappears from the rule without a message explaining why. Every change to a rule is recorded in the audit log with who made it.

Checking that it worked

Two tools, and one thing about the first that surprises people.

Test. Each rule has a Test button that sends immediately. It sends to the rule's recipients, not to you, with [TEST] in front of the subject. It skips both the quota and the duplicate check, so you can click it as often as you like — but if the rule points at four colleagues, all four get it. Scheduled templates build real data for a test, so what arrives is what they will actually receive.

Recent activity. The last 50 deliveries, including the essential alerts you never configured. Three statuses appear:

Scroll the table sideways for the remaining columns.

Delivery statuses in Recent activity
Status	What happened	What to do
sent	Accepted by the mail provider	Nothing. If it is not in the inbox, see below
failed	The provider rejected it or errored	Check the recipient address. It will not be retried
pending	Reserved, then the send never reported back	Treat as failed. It will not be retried

Test sends are deliberately excluded from this list, so a successful test will not appear here. Members who are not admins see recipient counts rather than addresses.

What you will never see here is a send blocked by your monthly cap. The cap is checked before the delivery is recorded, so a rule that has run out of allowance simply stops appearing — it does not show up as a failure. If a rule went quiet, check the usage card before you check anything else.

Four setups that work

Rather than switching everything on, here are four configurations that each cover a real situation without flooding anybody.

Scroll the table sideways for the remaining columns.

Starting configurations by operation type
If you are	Turn on	Why this shape
A solo seller on Free	Low stock digest, weekly, Monday 08:00	Weekly is about 4 sends a month, so it fits 25 comfortably. Daily would not.
A small team on Pro	Low stock daily to you; weekly growth recap Monday to you and your partner	About 30 + 8 to 10 of 200 emails (a month has four or five Mondays, and the recap goes to two people). The daily list is working material; the recap is context.
Running a returns desk	Warehouse scan summary weekly, plus the claim reminder daily at 3 days' lead	The two halves of claims work — what you have not filed, and what Amazon owes by a date.
A team already living in Slack	Any rule with a webhook and no email recipients	Slack does not count against the allowance, so a channel costs nothing.

Whatever you choose, set it up after your first Amazon import has finished. Three of the digests will send an empty table if there is no data yet, and each empty one costs you quota.

Traps worth knowing

Everything below is current behaviour, verified, and each one has cost somebody an afternoon.

Scroll the table sideways for the remaining columns.

Behaviour that is easy to get wrong
The trap	What actually happens
A daily digest on Free	Exceeds the 25-email allowance by itself and stops around the 25th, every month, with no warning.
Slack on the two warehouse reports	Saved and ignored. Those templates have no Slack form.
Turning digests on before the first import	Low stock, excess stock and warehouse performance all send an empty table rather than skipping, and each costs quota.
Deleting the delete-request rule	Brings the email back — the default sends it to all warehouse managers. Disable the rule instead of deleting it.
Clicking Test to see what it looks like	Sends a real email to everyone on the rule, not to you.
Expecting a failed send to retry	Generally not. That scheduled run is lost; the next one is at its normal time. (A send the provider rate-limited before accepting it is released, but the next 15-minute run no longer covers that scheduled time, so a scheduled rule rarely gets a second try.)
Assuming the receipt emails are preferences	Payment receipt, amount charged and new member joined are essential. No setting turns them off.

One more thing worth knowing

A daily digest does more than read your database. Before it renders, it can run a live Amazon sync and write the results, so the digest is also quietly keeping your inventory current. That is usually welcome — but it means the email is not a passive report, and a sync problem can show up as a digest that arrives with yesterday's numbers rather than as an obvious error.

Questions

Why did my digest stop arriving halfway through the month?

The monthly cap is the most likely cause. It counts one email per recipient actually sent, so a daily digest to three people costs about 90 a month. On the Free plan, which allows 25, a single daily digest to one person is blocked from about the 26th send. No email warns you, and a blocked send leaves no entry in Recent activity at all. The only signal is the usage card at the top of the Automated emails page, which turns amber from 80% and red with a "Monthly quota reached" message at the cap.

Can I stop the billing and trial emails?

No. Nine templates are classified as essential — trial ending, billing failed, payment receipt, amount charged, subscription cancelled, new member joined, first import finished, sync stalled and reconnect required. They always go to every owner and admin, they ignore the monthly cap, and they cannot be turned into a rule or switched off by anyone, including you.

Is there an unsubscribe link?

Yes, for the reports and alerts you configure. Each recipient gets their own copy with a "Stop receiving this email" link in the footer, and Gmail and Yahoo show their own unsubscribe button for it. Using it opts only that person out of that email (or, if they choose, every automated email from the workspace). They stay listed but shown struck out as unsubscribed, so owners and admins can see they won't receive it, and admins can't re-select them, even by deleting and recreating the rule; only the person can resubscribe, from their profile. Addresses that hard-bounce or mark an email as spam are suppressed automatically. Admins can still disable or delete a rule, or use Pause all. The always-on alerts have no unsubscribe link and cannot be stopped.

Do Slack messages count against my email quota?

No. The cap counts email recipients only, and Slack keeps firing even after the cap is reached. Slack needs Pro or Business, and the webhook URL has to begin with https://hooks.slack.com/.

Why is my Slack webhook doing nothing on the warehouse reports?

Two templates — warehouse scan summary and warehouse claim reminder — have no Slack representation at all. The field accepts your webhook and saves it, then nothing is ever posted. Both are email-only, and the interface does not currently say so.

Where do I set the low-stock threshold?

Not on the automated emails page. The low stock digest reads your organisation's dashboard setting, which defaults to 14 days of cover, and the excess digest reads a separate one defaulting to 45 days. Both live in Organization settings and changing either changes the emails for everyone in the workspace.

Does the Test button send the email to me?

No — it sends a real message to the rule's configured recipients, with [TEST] on the front of the subject. It skips the quota and the duplicate check, so you can click it repeatedly, and it deliberately does not appear in Recent activity.

An email failed. Will it be retried?

Generally no. A delivery is recorded before the send is attempted, so a failure leaves a row that blocks the same send from being retried. That scheduled run is lost and the next one happens at its normal time. If a send shows as failed, treat it as a missed report rather than a delayed one. The one exception is when the email provider rate-limits the send before accepting it: that reservation is released so a later run of the same event can try again. A scheduled rule rarely benefits, because the next 15-minute run no longer covers its scheduled time, so treat it as missed.

Keep reading

The returns evidence checklist

What to photograph and record on every returned unit, so a claim has evidence behind it instead of being reduced or refused for the lack of it. Set it up in about 30 minutes, on a phone you already own.

Returns operations · 9 min read

Also worth reading:Automated reports & alerts Local warehouse returns Team roles & audit log

All guides