Prerequisites
Understanding of Relay Network
Familiarity with "The Feed" - Ensure a clear understanding of our software Relay's messaging platform, including its functionalities and capabilities.
Onboarding Process - Knowledge of the onboarding process and data requirements for users within the Relay Platform.
Messages and triggering - Understanding of how messages are generated and triggered within "The Feed," including the events that initiate message notifications. When setting up an experience in CXB, remember to add a trigger nickname. The trigger nickname will populate in the custom journey activity when selecting a message. If you do not add a trigger nickname, the trigger id will populate in the custom journey activity.
TCPA Consent - Awareness of the Telephone Consumer Protection Act (TCPA) regulations regarding consent for messaging communications.
CCID (Client Customer Identification) - Understanding of how customer contacts are identified and managed within Relay.
Understanding of Salesforce Marketing Cloud
General Salesforce Marketing Cloud basics - Data extensions, journeys, and settings.
Installation of Packages - Ensure access to Salesforce Marketing Cloud Packages and knowledge of the installation process. Obtain the .zip package from your Relay Client Success or Implementation Manager prior to the installation.
Data Extensions - An understanding of each Relay related Data Extension and how each is used in the integration with Salesforce Marketing Cloud.
Relay Metadata Network Data - This data extension maps into Relay to fetch the client ID and the client keys when executing tasks. It essentially holds the API key required to call the Relay APIs, retrieving experience lists from the Relay platform or triggering a Relay experience within the Salesforce Marketing Cloud Journey Builder.
Relay Network Data - The data extension, relay_network_data, contains the fields utilized to onboard customers and/or trigger Relay experiences from Salesforce Marketing Cloud Journey Builder. It represents a firm’s entire customer base and the fields associated with those customers, however, the minimum, required fields are: CCID, product_group_id, phone_number, phone_consent_type. For a full data dictionary, review the Data Extensions section.
In addition to standard fields, Clients can choose to add extension fields starting with “EXT_” — these will be included when making onboarding calls.
NOTE: The Relay batch file and direct API connections do not source data from this data extension.
Starting Data Extension (Entry Source Data Extension) - Each Salesforce Marketing Cloud Journey requires a Starting Data Extension. This is the segment of the customer base that will be admitted into the specific journey and receive the Relay experience. Often, specific fields associated with the Relay experience are contained in this Starting Data Extension. These are known as “input_” fields.
NOTE: The customers being admitted into the journey are a subset or segment of the customers contained in the relay_network_data data extension and will be linked by the CCID when Building a Salesforce Marketing Cloud Journey.
Relay Package Configuration
The Relay package must be imported and configured individually within each Salesforce Marketing Cloud (SFMC) Business Unit (BU) where it will be utilized. Configuring the package at the BU level ensures that all required assets, permissions, and authentication settings are properly aligned with that specific environment.
Relay supports the following configuration models:
One Client ID to One Business Unit – Each BU is associated with a unique Client ID, providing clear separation of credentials, access, and data management. This configuration is recommended when Business Units operate independently or have distinct data governance requirements.
One Client ID to Multiple Business Units – A single Client ID can be shared across multiple BUs, allowing centralized credential management and simplified setup. In this configuration, all engagement data from Relay will be sent to a single Data Extension in SFMC. If data needs to be separated by Business Unit or use case, additional automation or data management processes may be required to segment or distribute the data appropriately.
The chosen configuration model should align with your organization’s security, data governance, and operational requirements.
Relay Package Options
Relay provides three package options to support different implementation and integration requirements:
Relay_Network_Package_Complete
Description: A comprehensive package that includes all components required for full Relay integration, combining both the API-based bi-directional data exchange and the SFTP batch process capabilities.
Components: Full set of Automations and Data Extensions covering installation, reporting, and batch processing.
Use Case: Recommended for organizations implementing the complete Relay integration across engagement, consent, and data management workflows for a combination of API-driven integrations and batch processing.
Relay_Network_Package_API
Description: Focuses on the bi-directional data exchange through Relay’s API suite, enabling real-time communication between SFMC and Relay. This package also includes the custom activity for Journey Builder, allowing dynamic message orchestration and response tracking directly within SFMC journeys.
Components: Automations and Data Extensions related to installation, reporting, and API-driven integrations (e.g., relay_response_log, relay_network_data, and relay_network_metadata).
Use Case: Ideal for environments prioritizing real-time API integrations and journey-based message delivery.
Relay_Network_Package_BatchProcess
Description: Supports batch file transfers via SFTP between SFMC and Relay. This package establishes the data flow for scheduled or large-volume updates of customer data, consent records, and onboarding details.
Components: Automations and Data Extensions used for managing SFTP-based data imports and exports.
Use Case: Suitable for teams managing periodic data syncs or operating in environments where batch data processing is preferred over API-based exchange.