Reviewing Approved Emails Before Sending

  • iPad
  • Online
  • Windows

Approved Emails can be marked as requiring additional review before being sent to recipients by adding the {{requiresReview}} token to the appropriate content. This provides an additional level of compliance checking by enabling the final contents of an email to be reviewed and approved before it is sent to recipients.

Additionally, this feature can be used in other forms of Approved Email, for example, Approved Email receipts for signature transactions, to hold sent emails until certain business conditions are met.

For example, Sarah Jones composes an Approved Email containing content designated as needing additional approval. When she sends the email to Dr. Ackerman, it is first reviewed by a compliance user, who views the entire rendered contents of the sent email. The compliance user notices non-compliant language present and rejects the email, providing a reason for his rejection. Sarah Jones is notified about the rejection and is able to view the reason provided by the compliance user. She composes another email to Dr. Ackerman addressing the reason for rejection and resends the email. The compliance user approves the email and it sends to Dr. Ackerman.

In another example, Sarah Jones visits Dr. Ackerman, who places an order for Cholecap. Her org has Approved Email receipts for signature transactions enabled, so she also sends an Approved Email serving as Dr. Ackerman’s receipt for the order. Sarah’s company requires receipts not be sent until confirmation of the order’s fulfillment by the vendor, so the receipt does not immediately get sent to Dr. Ackerman. Once the order is fulfilled, an external process updates the receipt’s status, sending it to Dr. Ackerman.

Considerations

  • Customers are responsible for creating a process to view, approve, and reject these emails
  • This feature can be used in conjunction with the Previewing Rendered Approved Email Content feature to view the rendered Approved Email exactly as it would display to participants, aiding in the approval process
  • Once an email is approved or rejected, its status cannot be edited again

Configuring Reviewing Approved Emails

To enable this feature:

  1. Enable Multichannel Alerts.
  2. Grant end users the following permissions:

    Object

    OLS

    Record Types

    Fields

    FLS

    Sent_Email_vod

    CRU

    n/a

    • Reject_Reason_vod
    • Review_Datetime_vod

    Read

  3. Grant integration users the following permissions:

    Object

    OLS

    Record Types

    Fields

    FLS

    Sent_Email_vod

    CRUD

    n/a

    • Email_Content_vod
    • Email_Content2_vod

    Edit

  4. Grant Approved Email reviewers the following permissions:

    Object

    OLS

    Record Types

    Fields

    FLS

    Sent_Email_vod

    RU

    n/a

    • Reject_Reason_vod
    • Review_Datetime_vod
    • Reviewer_vod
    • Status_vod

    Edit

  1. Activate the following Status_vod picklist values for all Sent_Email_vod record types:

    • Pending_Approval_vod
    • Approved_vod
    • Rejected_vod
  2. Ensure all appropriate VMOCs for the Sent_Email_vod object do not have a WHERE clause referencing the Sent_Datetime_vod field . This is because rejected emails do not have a sent datetime. Customers wanting to use datetime in VMOCs should reference the Capture_Datetime_vod field.
  3. Add the {{requiresReview}} token to all appropriate Approved Email templates.

    T his token does not render to end users in Edit or Preview mode of an Approved Email and does not render to recipients.

Sending an Approved Email Marked for Review

When an end user selects Send for an Approved Email including the {{requiresReview}} token, the email does not immediately send to recipients. Instead, the following process occurs automatically:

  • The Sent Email’s status is set to Pending, indicating the email must be approved by an enabled reviewer.
  • The following Sent_Email_vod fields stamp with the following information:
  • Email_Content_vod and Email_Content2_vod fields – Stamp with the final HTML content of the email
  • Subject_vod – Stamps with the subject of the sent email
  • User_Input_Text_vod – Stamps with any free text or rich text entered by the end user using the following format:

    [{“TOKEN NAME”: “User Input Text},{“TOKEN NAME”: “User Input Text”}]

    For example, [{"customText": "Example"},{"customRichText": "<b>Bold Example</b>"}]

  • The Sent Email’s status updates to Pending Approval.

Sent Emails with a status of Pending Approval can be reviewed by users via a customer-defined proces s and can be either accepted or rejected by updating the Status_vod field to either Approved_vod or Rejected_vod.

If the end user does not schedule the email and sends it immediately, the email must be approved by the reviewer within 14 days or else the email will not send even if approved.

When an email is approved or rejected, the following information stamps on the Sent Email:

  • Review_Datetime_vod – The datetime of the approval or rejection of the email
  • Reviewer_vod – References the CRM user who approved or rejected the email

If the reviewer approves the email, the email is sent to the recipient when the email is next processed by the integration.

If the reviewer rejects the email, they may enter a reason for doing so in the Rejected_Reason_vod field. Rejected emails are not processed and do not send to recipients. End users are notified of rejected emails via a Multichannel Alert.

End users can view approved emails on the account’s timeline.

Viewing Alerts for Rejected Approved Emails

When a Sent Email is rejected, the Approved Email end user who sent the email is notified of the rejection via an urgent-level Multichannel Alert. This informs end users the email was not sent and also provides an opportunity to learn why the email was rejected to prevent future rejections.

This alert displays the following information to the end user:

  • The reviewed datetime as defined in the record’s Reviewed_Datetime_vod field
  • The name of the Approved Email template used
  • The reason for the rejection as defined in the record’s Rejected_Reason_vod field