Configuring Notifications

A Notification sends an email or an in-app alert when something happens: a document is submitted, a field changes, a date approaches. It is configured in a form — no code — and it is the right tool for most "let me know when…" requests.

What already exists

Before building one, check whether GarmentFlow already covers it:

• Email digests — daily, weekly and monthly summaries for production, design, logistics and quality, sent by role.
• QC Alert Configuration — quality-specific alerts on defect rates and thresholds.
• Breakdown assignment — a machine breakdown assigns itself to Manufacturing Managers and escalates after four hours.

Notifications are for everything else, and for anything you want addressed to a specific person rather than a role.

Before anything will send

Email needs an outgoing Email Account. Awesome Bar → email account → check there is one with Enable Outgoing ticked and a default set. Without it, notifications are created and nothing arrives.

Test it by sending yourself a message from any document's comment box before you start debugging a notification.

Creating one

1. Awesome Bar (Cmd/Ctrl + K) → notification → Notification List → + Add Notification.
2. Fill in the header: - Name — what it does: Production Order put On Hold - Document Type — Production Order - Channel — Email, System Notification, Slack, or another configured channel - Enabled — tick when ready
3. Choose the event, the recipients and the message, below.
4. Save.

Choosing the event

Send Alert On decides what triggers it:

The two most useful in a factory:

Value Change — pick the field in Value Changed (status), and it fires whenever that field changes. Narrow it with a condition so it fires on the change you care about.

Days Before — pick the date field in Reference Date and set Days Before to 3, and every order gets a reminder three days before its end date. This is checked once a day by the scheduler, so it is not instant — it arrives in the daily run.

Narrowing with a condition

Condition is a Python expression evaluated against doc. It must be true for the notification to send:

doc.status == "On Hold"

doc.total_planned_qty > 5000

doc.status == "Released" and not doc.custom_customer_po_number

doc.priority == "High" and doc.docstatus == 1

Without a condition, a Value Change notification on status fires on every status change — including ones nobody wants an email about. Almost every notification wants a condition.

Keep it to a simple expression on the document's own fields. Anything needing a lookup belongs in a server script.

Choosing recipients

The Recipients table takes as many rows as you need, each of one kind:

Role-based recipients are usually right: people change jobs, roles don't. A notification addressed to a role keeps working after the person who asked for it leaves.

You can also add a Condition per recipient row, so one notification serves several audiences with different rules.

Writing the message

Subject and Message are Jinja templates. doc is the document:

Subject

Production Order {{ doc.name }} is On Hold

Message

<p>Order <b>{{ doc.name }}</b> was put on hold by {{ frappe.session.user }}.</p>

<ul>
  <li>Style: {{ doc.model_name }}</li>
  <li>Quantity: {{ doc.total_planned_qty }}</li>
  <li>Due: {{ doc.end_date }}</li>
  <li>Reason: {{ doc.custom_hold_reason or "not given" }}</li>
</ul>

<p>{{ frappe.utils.get_url_to_form(doc.doctype, doc.name) }}</p>

Notes:

• Use the fieldname, not the label.
• or "not given" avoids printing None.
• frappe.utils.get_url_to_form() builds a link straight to the document. Always include one — a notification the recipient can act on from their phone is worth ten they have to go and look up.
• Loop child tables the same way as in a print format: {% for row in doc.operation_plan %}.

There is also a Print Format option: attach the document as a PDF using a format you built.

Channels

Email — the default. Needs the outgoing account above.

System Notification — the bell inside GarmentFlow. Good for things that matter while someone is working, and don't warrant an email.

Slack — needs a Slack Webhook URL record. Create the incoming webhook in Slack, save it in Frappe, select it on the notification.

Others — SMS and WhatsApp — appear once configured on the site.

Some events deserve two notifications on two channels: a system notification for the team, an email for the manager.

Testing

1. Set Enabled off while you build it.
2. Set the recipient to yourself.
3. Turn it on, and make the change that should fire it on a test record.
4. Check Email Queue (Awesome Bar → email queue) — it shows whether the email was generated, and any send error.
5. Widen the recipients only once it fires correctly.

If nothing happens at all, check in this order: Enabled ticked; the condition actually true for your test record; the event matching what you did; the outgoing email account working.

A worked set

Four that most factories end up with:

Keeping them useful

The failure mode of notifications is volume. Once people filter them, they stop working, and you don't find out.

• One notification per decision. If nobody does anything differently on receiving it, don't send it.
• Prefer a digest for "what happened today". Notifications are for events that need attention now.
• Review them twice a year. Disable what nobody reads.
• Watch the noisy ones. A Value Change notification with no condition can fire hundreds of times a day.

What to do next

Continue to API & integrations to push events into other systems, or to build something of your own on top.