Message Senders

Message Senders help to deliver event-driven notifications to users based on certain key commerce activities. OrderCloud defines the activities, which could be things like order submitted, order shipped, forgot password, etc. and leaves it open to you to decide the presentation and notification format such as email, text, or perhaps something else completely.

Message Senders vs Webhooks

Webhooks are another OrderCloud feature that are event-driven and could conceivably be used to drive notifications, but webhooks are much less suited than message senders for this task. For example consider trying to build a notification to all users who are able to approve a newly submitted order. To accomplish this with webhooks you would need write code to cover the following steps:

1. Build a handler to receive the submit for your approval webhook

2. Take the high level order information and query the API for the rest of the needed order data

3. Query the API for all of the possible approving users (which can be complex)

4. Look up approving users' contact information

5. Send each message

In contrast, an OrderSubmittedForYourApproval message sender will retrieve all of the relevant information for you and send a single web request for each approver message that should be sent. This enables you to write a single, simple handler whose sole responsibility is to format the message and send it via email, text, or whichever other format you desire.

Message Sender Types

The message sender types below outline all of the different commerce activities that can trigger a notification via message senders. If you're not seeing an activity that you would expect, please reach out to us and we will consider adding it.

Note: A user must be active in order to receive a message. This means that user Active=true but also that buyer Active=true for the buyer organization they belong to or supplier Active=true for the supplier organization they belong to

Configuration Options

Before you can start sending messages you'll need to decide which approach you want to take to to implement message senders. There are three different configuration options ranging from least to most control. Please read the following sections for more detail.

Default Sender

This is our no code option, and should only be used for testing purposes. It sends emails with OrderCloud's Mailchimp account as well as with our own templates. There is nearly no setup to get going but it also means there is no control over the email templates, sender, or subject line.

To enable this option:

1. Create a new delivery config with a Mailchimp delivery target and a null ApiKey

1{
2  "Name": "test emails",
3  "Enabled": true,
4  "DeliveryTargets": {
5    "Mailchimp": {
6      "ApiKey": null
7    }
8  }
9}

1. Create a new message sender with the DeliveryConfigID of the resource created above and the desired MessageTypes

2. Assign the message sender to the relevant parties OR use AllowAllBuyers if you don't need explicit assignments

Your Own Mailchimp Account

This is our low code option that gives you a bit more control - you are able to provide your own custom email templates but the actual sending of the emails is handled by OrderCloud. This option requires that you have your own Mailchimp account.

To enable this option:

1. Create each of your email templates in Mailchimp. Refer to this table to determine which variables are available to render in your email template

2. Name your templates so that they match MessageType exactly

   1. If you have a need for multiple templates for the same MessageType, for example you have multiple Buyer companies and need custom branding for their respective emails, you'll need to provide some custom configuration details in xp, which is explained below
   2. Your templates must include a subject and from email address

3. Create a new delivery config with a Mailchimp delivery target, include your ApiKey

4. Create a new message sender with the DeliveryConfigID of the resource created above and the desired MessageTypes

5. Assign the message sender to the relevant parties OR use AllowAllBuyers if you don't need explicit assignments

If you have multiple MessageSenders and need to override the template names, you'll need to include the following data in each MessageSender xp:

1"xp": {
2    "MessageTypeConfig": [\
3      {\
4        "MessageType": "ForgottenPassword",\
5        "TemplateName": "ForgottenPassword-Buyer1"\
6      },\
7      {\
8        "MessageType": "NewUserInvitation",\
9        "TemplateName": "NewUserInvitation-Buyer1"\
10      }\
11    ]
12  }

Custom URL

In this option you provide OrderCloud the URL to your publicly available endpoint that will receive the event payload and is responsible for formatting as well as sending the notification. As you can imagine this grants you the most amount of control but it also requires more work on your end to accomplish. Here are a few reasons you may decide to go down this path:

• You want to use a different messaging provider than Mailchimp

• You want to send more than just emails such as texts or maybe something else entirely

• You need your notifications to include data that isn't available in the normal event payload

• You need to add some additional business-specific decisioning logic when sending an email

To enable this option:

1. Create and host a custom endpoint to receive and process the event payload

2. Create a new delivery config with a MessageSender delivery target, include your custom Endpoint and optionally a Secret

3. Create a new message sender with the DeliveryConfigID of the resource created above and the desired MessageTypes

4. Assign the message sender to the relevant parties OR use AllowAllBuyers if you don't need explicit assignments

Creating the custom endpoint is going to be the most laborious part of implementing this option. To help you out we've created a .NET starter project that demonstrates how to handles these types of events and has examples for sending notifications from Mailchimp, Sendgrid, and Twilio. Check out the payload models for each message type.

Here are a few other things to keep in mind as you're building your endpoint:

• We highly recommend validating every incoming requests against the Secret sent along with each request to your endpoint.

• Use the special variable {messagetype} in the custom URL provided to OrderCloud. This lets you define a single message sender configuration that can handle different message types. For example the custom url https://my-message-handler/{messagetype} that has opted in for an OrderSubmitted and ForgottenPassword message type will receive requests to the endpoint https://my-message-handler/ordersubmitted as well as https://my-message-handler/forgottenpassword.

• If your handler needs elevated permissions to complete its work you may consider defining ElevatedRoles this will grant your endpoint a token for the recipient user that additionally has any elevated roles defined. This can help simplify your logic especially if your handler is a one-off serverless function for example.

• Like most other entities in OrderCloud, Message Senders come with extended properties which you can use to store business specific data to drive custom behavior. Please note that xp will come through as ConfigData in the event payload.

• Check out our default templates to use as a starting point.

Custom Email Templates - Mailchimp Merge Vars

If you're using our Mailchimp integration and providing your own custom email templates then you can use these tables to determine which variables are available for you to render in your email templates.

Variables for ForgottenPassword and NewUserInvitation

Variables for Order Emails

Variables for OrderReturn

Includes all of the variables for order emails and additionally the following:

Variables for ShipmentCreated

Includes all of the variables for order emails and additionally the following:

Variables for OneTimePassword

Message Sender Event Payload models

If you are building a custom message sender it is necessary to understand what kind of payloads your endpoint handler will receive. The first table lists properties common to all message types. The tables below that one are the event payloads specific to each message type.

Generic Payload (not event specific)

Event Body for ForgottenPassword and NewUserInvitation

Event Body for Order Events

Event Body for OrderReturn Events

EventBody for ShipmentCreated

Event Body for One-Time Passwords

Conclusion

You should now have a good understanding of what message senders are, how they differ from webhooks, and the different implementation options at your disposal.