Portal notifications in CustomerGate 365

Three gates in front of every message

Three switches stand in front of every message, and all three are there because none of them is enough on its own:

1. The company's master switch. Portal Notifications Enabled on CustomerGate Setup is off after a fresh installation, and nothing turns it on at an update either; only an administrator does that. With it off, nothing is queued and nothing is sent, whatever anyone has chosen. Without this switch, a company that updates could start mailing on the strength of choices nobody remembers, from an environment copy for instance.
2. The person's own choice, per kind, on their own portal link. All five are off until they switch them on in the portal, and they are the only one who can. Consent that somebody else gives for you is not consent.
3. A re-check just before sending. Between queueing and sending there is at least one mail round, and in that time somebody may have left. Switching off therefore works at once, including for messages that were already queued.

The first two gates already stand at queueing and not only at sending, so that turning the master switch on does not immediately send out a month of backlog.

The five kinds

Quote Ready

A quote for this customer has been released.

Order Confirmed

An order for this customer has been released.

Shipment Posted

A shipment to this customer has been posted.

Invoice Posted

An invoice for this customer has been posted.

Request Received

A quote request from this customer has come in through the portal.

There are no other kinds, and that is a choice. Every kind above concerns the customer themselves and is something they would otherwise only see by signing in. A portal that mails about events a customer cannot place is filtered away within a month, and then the message that does matter no longer arrives either.

The five sit per portal user and per customer, because they belong to the link. Somebody who buys for two companies can want shipment mail for one and nothing for the other.

What inside sales can do here

Read. The portal user card shows which kinds are on, and they cannot be set there; there is no bulk action that switches them on either. This list itself is read-only: rows arise at a release or a posting and disappear with the cleanup run. Adding a message by hand would produce mail nobody asked for, which is exactly what this whole arrangement prevents.

The list

Created At

When the message was queued.

Kind

What the message is about. The portal user switched this kind on themselves.

E-mail Address, Customer No., Document No.

Who the message is for, which customer it concerns, and which quote, order, shipment, invoice or request.

Sent At

When the message was sent. Empty means the mail round still has to pick it up. A message that is no longer wanted also gets a time here, without anything being sent.

Failed Attempts, Last Error

How often sending failed and what went wrong last time. Above the maximum in the setup, the round leaves this message alone.

Language Code

The language the message is written in. It comes from the customer card, otherwise from the inside sales language in the setup. Hidden by default.

The text of the message is not here: it is composed at sending time, in the customer's language at that moment. What was actually sent is in Sent Email in Business Central. A row is amber while it has not been sent, and red as soon as an attempt has failed.

From posting to mail round

Messages are queued where they arise, in the middle of a release or a posting, and nothing else happens there: one row inserted, no mail, no HTTP. The mail round that runs anyway sends them. This is not delay for its own sake: a missed notification is an inconvenience, but a posting that falls over a notification costs a day's work. For the same reason the app checks before writing whether it may write, instead of catching an error afterwards: the warehouse employee posting a shipment need not carry any CustomerGate permission set.

What a message says

One message per event, in the customer's language, naming the document and pointing at the portal. Every message says why it was sent and where to switch it off. That pointer goes to the portal, where the recipient signs in as usual. There is deliberately no unsubscribe link that works without signing in: such a link works for whoever holds the e-mail, and it would be the one endpoint in this app that accepts an address and acts on it.

Cleanup

Sent messages disappear thirty days after they went out, with the cleanup run: what a sent message proves is in the recipient's mailbox a month later, not here. A message that has not been sent yet stays; that is not an old trace but work still to be done. If somebody erases all the data for an e-mail address, queued messages for that address are deleted outright, because somebody who asks to be erased should not get mail tomorrow.

When a message strands

1. Is there a time in Sent At? Then the message has gone, or it was no longer wanted at the moment of sending.
2. If Failed Attempts is above zero, read Last Error. Usually it is the e-mail account or the recipient's address.
3. If nothing was tried at all, check on CustomerGate Setup whether the mail job is on hold and whether there is an e-mail account.
4. Is Portal Notifications Enabled on, and has the portal user switched this kind on themselves? If either is off, nothing was queued either.
5. Sent Email in Business Central shows what actually left.