#TrailblazerCommunity190 discussing

Hi Divyesh, 

No,

in the Activity Timeline.  

Renaming Log a Call → Visit changes the action label, but Salesforce still identifies the activity internally as a Call, so the timeline shows "logged a call."

1.  Flow/Apex cannot change this standard timeline text.
2.  If the wording is not mandatory, keep the standard functionality and use a custom field like Activity Type = Visit. 
3.  If the client strictly needs "logged a visit," the recommended solution is a custom LWC Activity Timeline/component where you can control the displayed text. 
    
   Thank you.

Hi Mohammed,

Looking at your screenshot, the error message reads: "The 'Solarbot Pipeline by Stage' component is the incorrect size or in classe incorrect position."

In Salesforce Lightning Dashboards, the automated checker strictly verifies the exact grid dimensions (width and height) and coordinate placement of each component. Based on your layout, the SolarBot Pipeline by Stage component is currently positioned spanning across the left side, but its height or column span does not match the precise specifications required by the superbadge instructions.

1.Open Dashboard Builder:Dashboard Layout. 

Open the SolarBot Impact Dashboard in Edit mode. You can verify success when you see the grid configuration handles on your dashboard components. 

2.Adjust Component Width and Height:Component Sizing. 

Click and drag the corners of the SolarBot Pipeline by Stage component to match the standard sizing and layout guidelines specified in the superbadge instructions (typically a specific number of columns wide and rows high, ensuring it aligns symmetrically with neighboring components). You can verify success when the component grid boundaries snap to the correct layout proportions. 

3.Save, Refresh, and Re-run:Save and Check. 

Click Save, refresh the dashboard view, return to Trailhead, and click Check Challenge. You can verify success when the green completion checkmark appears.

Hi Guilherme, Custom Keys aren’t required for basic push notifications. They’re used when the app needs to receive additional key-value data in the push payload, for example to support tracking, deep linking, or custom app behavior. The mobile app code needs to be implemented to handle those keys. 

For the basic MC Next setup, you’ll need to configure the mobile app and the appropriate iOS/Android push service credentials, then configure the SDK in the app to receive push notifications. 

So if the implementation doesn’t require any custom data or app-specific behavior, Custom Keys generally aren’t necessary. If you share what the other company is asking you to configure as the Custom Keys, it may be easier to determine whether they’re actually needed. 

Hi Uttej, could you share a bit more detail about the CML configuration and the cardinality you’re trying to set for each level? 

In particular, it would help to know whether the GrandParent → Parent → Child relationships are configured as nested bundle products and what cardinality values you’re trying to apply at each level. If possible, please share the relevant CML snippet or a screenshot of the Browse Catalog configuration and the behavior you see after saving. 

That will help determine whether the cardinality can be applied to all three levels in this configuration.