Testing, publishing and exploiting communications
01The catalog links content to business #sec_eb7a12db
Open Settings > Communication > Email Catalog.
A template is not just a layout. It is associated with a business event, a language, a publication status and, when there are multiple variants, a default template. The catalog thus allows the content to evolve without modifying the operation of a campaign.
The global templates provided by REVIEWIT serve as a foundation. The subscription can copy them into its catalog to create a locally governed variant. The copy then becomes an autonomous template: it can be adapted, tested and then published without altering the global reference.
02Understanding template selection #sec_3b7d052a
During an automatic send, REVIEWIT first looks for the published local template that matches the event and language. Failing that, it uses the platform reference in that language, then its English variant. An integrated English resource provides the last fallback for structural events.
The Published status authorizes use. The Default status is also operational: a published template that is not the default variant for its event-language pair will not be chosen automatically.
03Using variables #sec_06b16195
Variables inject the real context into the template. Their syntax is case-sensitive and uses a single pair of braces: {CampaignTitle}, {ResourceName} or {ReviewerName}, for example.
They can be used in the subject, preheader, body and HTML attributes. In an HTML file, the content of <title> also becomes the subject of the message. Values are encoded so that text containing < or & cannot modify the HTML.
A variable without a value remains visible as is in the email. This is a useful error signal during testing, but it should not reach recipients. Case matters: {ResourceName} and {resourcename} are two different identifiers.
04Variables available by event #sec_9bbe09a2
The following list gives the safe variables to use in currently issued templates. An event marked Dormant is known to the catalog, but is not yet triggered automatically.
The [Email Variables: Reference and Examples](tuto-communication-factory-variables) sheet separately groups the syntax, the detailed dictionary and the checks to be performed.
Reviews
| Event | Safe variables | Recipient | Status |
|---|---|---|---|
| ReviewsAssigned | ResourceName, CampaignId, DueDate | Reviewer | Active |
| ReviewReminder | ResourceName, CampaignId, DueDate | Reviewer | Active |
| ReviewsExpired | ResourceName, CampaignId, DueDate | Reviewer | Active |
| EscalationNotice | ResourceName, CampaignId, DueDate | Disenfranchised reviewer | Active |
| EscalationReceived | ResourceName only | Escalation recipient | Active |
| DelegationReceived | ResourceName, DelegatorName, Reason | Delegate | Active |
| RequestReassigned | ResourceName, ReassignedByName, Reason | New reviewer | Active |
| PendingReviewsDigest | None | — | Dormant |
EscalationReceived has multiple emission paths. Some also provide EscalatedByName and Reason, others CampaignId and DueDate . Only ResourceName is guaranteed in all cases: use this intersection in the default template.
Challenges and decisions
| Event | Safe variables | Recipient | Status |
|---|---|---|---|
| ChallengeRaised | ResourceName, ResourceType, Solution, OwnerName, Argument, AnswerDueDate, DaysToAnswer | Reviewer or owner | Active |
| ChallengeAccepted | ReviewerName, NewDecision, ResolutionNote | Challenger | Active |
| ChallengeDeclined | ReviewerName, ResolutionNote | Challenger | Active |
| ChallengeWithdrawn | OwnerName, WithdrawnDate | Reviewer | Active |
| EscalatedDecisionNotice | ResourceName, DecidedBy, Decision, CampaignTitle, Reason | Informed party | Active |
| ChallengeReminder | None | — | Dormant |
| DecisionAmended | None | — | Dormant |
Deletions, access and consultation
| Event | Safe variables | Recipient | Status |
|---|---|---|---|
| DeletionRequested | ResourceName, ResourceType, Solution, RequesterName, Reason, Comment, SizeFormatted | Approver | Active |
| DeletionCancelled | ResourceName, CancelledByName, CancelledDate | Requester | Active |
| DeletionProcessed | ResourceName, ProcessedDate | Requester | Active |
| DeletionRejected | None | — | Dormant |
| AccessRevokedNotice | ResourceName, RevokedBy, Reason, CampaignTitle | Access holder | Active |
| ExceptionExpiring | None | — | Dormant |
| AdviceRequestedNotice | ResourceName, RequestedByName, Question | Consulted person | Active |
| AdviceReceivedNotice | ResourceName, AnsweredByName, Answer | Requester | Active |
| AdviceRedirectedNotice | ResourceName, RedirectedByName, NewRecipientName | Initial requester | Active |
| GracePeriodEntered | None | Subscription administrator | Dormant |
05Choosing a presentation adapted to the variable #sec_62b17f16
ResourceName can be a readable name or a reference like #123 . Present it in a labeled block rather than in a sentence that assumes it is always a name.
Dates are already formatted by the service that issues the event. Do not attempt to reformat them in HTML.
Answer, Question, Reason, Argument, Comment and ResolutionNote are free texts entered by people. Display them as quotes or in a dedicated block, never inside a sentence whose meaning they could change.
CampaignId is a numeric identifier. Use CampaignTitle when it is offered and the template needs a readable title.
06Variables not to use for the time being #sec_8cd304e6
{DeepLink} and {SettingsLink} still appear in some historical templates, but they are not fed by current events. Do not add a button or link that depends on them as long as they are not among the available variables of the event.
Some historical manual reminders still use the {{ReviewerName}} syntax. It is not equivalent to the {ReviewerName} syntax of automatic notifications. Always test the template in the journey that will actually use it.
07Preview and send a test #sec_47ce789e
Before publishing:
- open the template preview;
- check the subject, preheader, and layout;
- provide realistic values to all present variables;
- choose an active sender;
- send the message to a controlled address;
- check that no {Variable} text remains in the received message.
An accepted sending proves that the REVIEWIT-provider chain is working. It does not alone prove delivery to the inbox, opening of the message, or recipient action.
08Expected assistance in the editor #sec_6baa51e4
This reference is intended to directly feed the editor: when the administrator chooses an event, a palette of Available Variables can display only the relevant variables, their definition, and an example, then allow them to be inserted at the cursor.
Validation can then indicate before sending:
- a guaranteed variable, ready to be used;
- a contextual variable, absent from certain paths;
- an unknown or unavailable variable;
- incorrect syntax, especially double braces;
- a variable present in the HTML but without a test value.
The page you are reading remains the functional reference: it allows you to prepare and control a template, even when this contextual help is not yet offered by the editor used.
09Publish with discernment #sec_f4bd4f8e
Publish only the variants ready to be used. For each event and each necessary language, check that only one published template bears the default status.
A template associated with a dormant event can be previewed and tested, but it will not be sent automatically as long as the corresponding business function does not emit it.
10Daily operation #sec_e7735df5
The configuration is ready when the following five elements are met:
- an active sending route and designated by default;
- a verified then activated domain;
- an active sender and consistent with this route;
- a published and default template for the event and language;
- a test received without unresolved variable.
After any secret rotation, DNS modification, or route change, perform a complete test again. Also keep an eye on the provider's quotas, rejections, and deliverability returns: an accepted sending request is not proof of delivery.
11To remember #sec_f6d8bee2
The catalog governs the meaning of the message; the domains and senders establish its legitimacy; the provider ensures its delivery. The Subscription Manager brings together these levers without confusing their responsibilities.