​Hey all,

Across a customer base, it’s quite common to not have a designated customer success advisor for each and every single account.

It’s equally common to need to engage with your entire customer base at once through digital CS and lately I’ve seen various posts relating to challenges in Dynamic JO when it comes to generating fallback senders for several reasons:

1. We no longer need to map our source fields to a “sender email” field in Dynamic JO,
2. We can’t generate case statement fields as an email data type,
3. A program can only have one calculated source (query, data designer) since we no longer need to map fields  

The good news is that the changes brought about by Dynamic JO in that regard haven’t hindered our ability to reliably generate fallback senders. If anything, they’ve “forced” us down a more efficient, reliable and sustainable route (or so I think 😊).

So I thought I’d share our approach to:

1. Handling fallback senders in Dynamic JO (which also works in Advanced😊) and CTAs assignees
2. Reducing the maintenance of Gainsight assets (rules, data designs, JO queries...) leveraging fallback senders/assignees

Our approach is to designate a regional fallback sender, but this approach can be adjusted to leverage other data dimensions.

The ingredients

• Access to data management (creating and updating data management objects)
• Access to user management (optional)
• Data designer (to create templates – and I’ll leave you all to read @spencer_engel 's great post on the value of templates)
• Report Builder (optional)

The recipe

Step 1:

1. In data management, create a new low volume object called “Fallback Sender Details”
2. Create the following fields custom fields in addition to standard and system fields for the object:
   1. Fallback Sender
      • Data Type: GSID
      • Mapping: User Id
      • Lookup: User::GSID
   2. Region
      • Data Type: Dropdown List
      • Mapping: N/A
      • Lookup: N/A
   3. Sub Region
      • Data Type: Dropdown List
      • Mapping: N/A
      • Lookup: NA
3. Create or upload records for each combination of region + sub region, and set the fallback sender GSID for each combination.

This object will serve as your one place to update fallback sender logic and cascade it down to all of the Journey Orchestrator programs you run in one click.

This can be built with a different logic of course; ours is to designate a regional fallback sender.

TIP: 

If one of your fallback senders in a generic email address such as customer success @ your domain.com, create it as an internal collaborator user in user management so you can assign it as the fallback when it makes sense.

Step 2:

In data designer, create a new template (templates are an awesome reusable component as Spencer put it recently).

Consider the key data source for your program:

• Is it a relationship program or a company program?
• Do you like to work directly from the relationship/company person object or do you usually start with the relationship or company object, and later append your participants?

Step 3:

• Create a fetch lRelationship or Company] data task with all the fields you need from that object, including your standard sender’s GSID (e.g. the CSM GSID). There’s no need to include the CSM Name, Email or Job Title at this point.

You’ll notice a “transform” task right after this task in the template overview screenshot: that task isn’t necessary to support this approach. In my world, it’s needed to transform some of the relationship data for later use.

Step 4:

• Create a fetch pFallback Sender] data task with all the fields you need from that object.

Step 5:

• Create a merge left the task you created at step 3 with the task you created at step 4 on Region and Sub Region, or the other dimension(s) you have chosen as your merge condition(s).

This task will provide you with the fallback sender for each relationship or company, in addition to your standard sender.

Step 6:

• Create a transform task to generate the final GSID of the sender. If you have a standard sender for the account, you’ll keep that value. If it is null, you’ll want the fallback sender ID to be used.
• Create a “Program Sender ID” case statement field where:
  • If relationship/company CSx ID = null, then Program Sender ID = Fallback Sender ID
  • If relationship/company CSx ID =/= null, then Program Sender ID = Standard Sender ID

In my case, the default is always the assigned customer success advisor on the account.

Step 7:

• Create Fetch /User] task including the following fields (or more, depending on your mapping needs):
  • User GSID
  • User Full Name
  • User Email
  • User Job Title

These are my go-to, used in all my programs to mimic a real “Outlook” or “Gmail” signature. This can be complemented with a phone number, time zone and whatever other data point is required.

Step 8:

• Create a merge left of the tasks you created at step 6 and step 7 to append the fallback sender details to your original relationship or company data set.
• Merge left Program Sender ID with User GSID

• Make sure to unselect the User GSID field from the Fields tab. No need to have the same value twice in your data set since you already have Program Sender ID from your left data set.

 
You’re now ready to roll!

At that point, you have a reusable data set you can bring in to any Data Design, Rule, Journey Orchestrator query (Dynamic Journey Orchestrator) and to which you can append relationship persons, company persons and/or a heap of other data to generate your final participant data set.

When you’re facing turnover in CSMs, you can easily change all your always-on programs’ logic, CTA rules or other rules and data designs in one click from the Fallback Sender object in Data Management… OR you can go to step 9 😀. 

Step 9:

If you need users without data management access to maintain the fallback sender records, create a report on Fallback Sender from Report Builder including all the records in the object and place it on a dashboard shared with relevant users to enable them to make in-line changes to the report.

---

Hope you’ve found this guide useful, and you can adjust it to your fallback logic and your data structure and typical source logic (company vs. relationship, or company person vs. relationship person). 

This approach has been a lifesaver for us.

And even if you don’t need to determine the fallback from one place to update all destinations, generating fallback senders as GSIDs provides a lot more flexibility than generating them directly as emails (in string data type fields).  

Thoughts? Questions? Let me know in the comments. 

A