Here you can find all my Salesforce IdeaExchange contributions. Let's make the change!
_Job Data View field that stores timestamp for the email delivery (when it successfully reached the target Email Service Provider). It is currently impossible to get delivery time for emails sent via Journey Builder.
It is happening, however, only for Journey Builder emails. Sends via any other methods (for example, Send Flow) are correctly displaying the delivery time.
I see it as a massive limitation for automations focused on keeping the database clean and debugging sends.Vote on IdeaExchange
As per the documentation,
_DataSourceName personalisation string should show the communication audience's name. It covers lists, data extensions, groups, and filters.
It works when the email is sent via Email Studio -> Email -> Content -> Send flow. However, when we send an Email (or SMS) from Journey Builder,
_DataSourceName shows "All Subscribers" instead of the Entry Data Extension name. It is true for both Multi-Step Journeys and Single Email Sends.
Vote on IdeaExchange
_DataSourceName should show Entry Data Extension Name for Emails in Journey Builder. It is handy to debug from Send Log and create dynamic logic in emails based on the Data Extension naming convention.
Salesforce Marketing Cloud Journey Builder offers many out-of-the-box Activities and the possibility to create or download custom ones from AppExchange. However, there is a space between those solutions that Salesforce can cover to empower Marketing Cloud users. An out-of-the-box Script Activity, similar to the one available in Automation Studio.
Flexible enough to offer countless possibilities to SFMC power users without the complexity of creating a custom solution with the whole hosting, scalability and security considerations.
Right now, it requires either:
- Stitching multiple Journeys and Automations with status-capturing Data Extensions to let members flow through the mix or
- filthy tricks with scripting in emails and, in the end, raising an error to block it from sending (quasi Script Activity with bad impact on reporting, performance, speed and super messages).
Salesforce can solve it. Below are two possible solutions (and a bonus one for even more performance-oriented fun):
- Minimum Valuable Solution: Script Activity with the same features as in Automation Studio. The possibility of executing SSJS (or even AMPScript to optimise performance) against every Journey member would allow for pre-send updates of data from external systems using HTTP functions to ensure that crucial personalisation details are up-to-date.
- Solution Deluxe: Extension of the previous idea to define various paths based on a predefined value in the script. Think about custom decision splits using out-of-sfmc data that allow you to change the Journey path based on real-time information from external systems.
- Bonus Solution: There is also a place for a much less system-heavy script activity on the side. One that captures all members that get to that Activity and in predefined cadence (for example, every hour), if there is at least one member available, executes provided script once. Think of it as a mix of Wait and Script Activity that allows executing logic applied to groups. Use cases? Lazy update of the personalisation-source Data Extension that happens only if there are members that would need it. Or performance check of the subsequent communication to decide whether the members should receive it. All with the performance impact of one script execution per hour - regardless of the number of members.
The Behavioral Triggers Content Block for Emails is an excellent tool for easy drag-and-drop creation of Abandoned Engagement communication. But it is missing one powerful feature — the ability to personalise the email with customer data.
It is already available in the form of:
- Einstein User Attributes that we can pass through the
- The request used in the back end of the current Behavioral Triggers Content Block; by adding "&user_attributes=attributeName" to the endpoint.
- Code of the existing Behavioral Triggers Content Block responsible for creating AMPScript variables based on the Einstein User Attributes data.
However, as the Einstein User Attributes are neither added to the request by default nor configured in the User Integrace of the Content Block, to get this data in the email, one must create yet another, the same call with the above query parameter added. Neither user friendly nor optimal due to expensive
HTTP.Get function running twice in such a scenario.
Salesforce can fix it. Below are two solution tiers:
- Minimum Valuable Solution: Add the required query string ("&user_attributes=X,Y") with all potential Custom Einsteins User Attributes to the request URL built within the Content Block code.
- Solution Deluxe: Improve the above with the UI-enabled selection of needed Profile Attributes, just as available with Product Attributes.
Behavioral Triggers Content Block allows for easy out-of-the-box use of abandoned engagement data in our Emails. It neatly pulls the Catalog items that captivated the customer's attention and displays them for win-back purposes. Of course, each item links back to its e-commerce page.
Its implementation is, however, leading to a problem with tracking. My favourite solution - Parameter Manager with Web Analytics Connector - is not working on the Behavioral Trigger Content Block. Neither can we add the tracking parameters manually, as there is no such option in the UI.
Right now, there are only two ways to add the UTM's:
- Add them to the Catalog directly - this adds them for all scenarios connected to Einstein or Behavioral Triggers. Not helpful, as in most cases, we want to differentiate various personalisation placements by using distinct UTM tracking.
- Create a Custom Behavioral Trigger Content Block - now we will be able to leverage direct links from
IGO_PRODUCTATTRIBSadd tracking to them in the product's HTML template. Okay, but not easy and make you lose click data for Einstein Recommendations.
Salesforce can fix it. Below are two possible solutions:
- Minimum Valuable Solution: Add a text box to a Behavioral Trigger Content Block configuration menu to add our custom tracking. The Content Block should apply the provided tracking query to each link. AMPScript support included.
- Solution Deluxe: On top of the above solution, Marketing Cloud should consider the Parameter Management to allow for a mix of global UTM's from Web Analytics Connector and local from the new text box in Behavioral Trigger Content Block configuration.
There is, however, an area for an easy improvement on that idea to make it much more flexible and ready for real-world scenarios. Salesforce can do it with two solutions:
Just as there are Custom Attributes for the Product Catalog, it would be great to have a similar option on the cart itself. Product Catalog ones are global - shared for all Customers interested in selected products. There is a need for something more unique and customer-specific.
It is already available in the form of an optional
price attribute of
trackCart Collect.js Data Layer that contains individual price that does not impact the Product Catalog. It would be great to have the possibility to add a few more, available in
trackCart Collect.js and the response from Einstein Backend (IgoDigital).
Use case? Sure. Coupon Code Name, Coupon Code Discount (either integer or float for per cent value), added Personalisation, Voucher ID. All those tools are frequently used in e-commerce and would be perfect for a
trackCart layer. Suitable for personalisation, perfect for passing data needed for rebuilding the cart.
This one is an extension of the above idea. We already have a way to decide which Product Catalog Attributes are displayed in the Behavioral Trigger Content Block. But in many cases, when I use Abandoned Cart, I would like to show
trackCart individual price (including applied coupons) instead of the global Catalog one. It could also be helpful for some Custom Cart Attributes from the previous solution.
Below are three solution tiers:
- Minimum Valuable Solution: Add
amountin the response from the IgoDigital) available for selection when defining fields shown for products in Behavioral Trigger Content Block.
- Nice Solution: On top of the first point, add two additional (optional) attributes to
trackCartCollect.js and IgoDigital response:
couponCodeDiscount- and make them also available for selection in Behavioral Trigger Content Block.
- Solution Deluxe: On top of the first point, add the possibility of defining Custom Cart Attributes in the UI and leveraging them in
trackCartCollect.js and IgoDigital response. Just as with Custom Profile Attributes / Custom Product Attributes. Additionally, make them also available for selection in Behavioral Trigger Content Block.
The current version of Behavioral Trigger Content Block is not rendering correctly on Yahoo, AOL and Windows Outlook. On those Email Providers, the product text is not displayed, and the customer only sees the images.
The reason for this is using
rem units font-size for product descriptions -
<td class="mcbt_name" style="padding: 0; font-size: 0.8125rem; padding-top: 10px; text-align: center; width: 100%; max-width: 310px;">--name--</td>
rem units are currently not supported by Yahoo, AOL and Windows Outlook (Can I Email) which leads to those Email Providers ignoring this parameter. When this happens, the font-size value is inherited from the parent that have font-size configured.
And for Behavioral Trigger Content block that parent is a
<td> parameter within header
markupFragment. Unfortunately, it has
<td class="multi-column" style="padding: 0; text-align: center; font-size: 0; padding-top: 10px; padding-bottom: 10px;">
There should be no
rem units used in the Behavioral Trigger Content Block code and instead a standard
px font-size assignment for the Block to render correctly.
SMS Blackout allows blocking SMS sends in the chosen timeframe. Currently, SMS Blackout can be configured based on Account Timezone.
However, it would be much better for multi-country clients to configure the Blackout period based on the recipient's local timezone. MobilePhone locale is perfect for implementing this.
This way, it would be possible to create, for example, a single SMS Blackout for nighttime and apply it for each contact regardless of the timezone. The locale is already there for MobileConnect and can be leveraged for determining timezone offset.Vote on IdeaExchange
Content Builder is great for creating and neatly organising assets in Marketing Cloud, but it has one huge issue. Folder access management.
There are already great Ideas on expanding the folder rights, so in this Idea, I want to focus on something different - and much easier to fix for Salesforce.
When settings permissions for a Marketing Cloud User or Role, there are options that control the rights to Shared Folders of Content Builder. As with Shared Data Extensions Folder permissions, you can decide what the user or role can do with Shared Content Folders.
However, there is one huge difference:
- With Shared Data Extension Folders, when you remove all permissions, the user or role can no longer see Shared space and effectively loses access to all Shared Data Extensions.
- With Shared Content Folders, when you remove all permissions, the user or role will not see the folders, but they will still see the Shared Folder tab and - what's much worse -
All Shared Contentsection displaying all the Content assets stored within Shared Folders.
As SFMC applies the permissions to read and edit content to both local and shared assets, every person with edit rights can change assets in a Shared Content Folder - event if they do not have permission to that folder.
This behaviour breaks a prevalent use case of having local folders available to all creators while limiting shared folders only to administrative roles. It is possible (and very useful) for Data Extensions. But not for Content Builder, as everyone can access all administrative-level assets (like master templates or crucial content blocks).
The fix is straightforward - if the current user does not have any permissions to Shared Content Builder Folders, it shouldn't see either the
All Shared Content section or even the Shared Folders tab. That's it. It would then mirror the Shared Data Extension folder permissions and enable the local/administrative access split use case.