#TrailblazerCommunity191 utenti parlano di questo argomento

Hi Riggins,

The industry consensus across enterprise Salesforce teams is clear: do not use Marketing Cloud Content Builder as your primary video asset library.

Content Builder is designed for lightweight email/web assets (images, logos, HTML snippets, and documents), not for source-quality video management or social asset version control.

Here is the standard, scalable architecture most marketing teams use to bridge Instagram video content with Marketing Cloud:

1. Centralize Master Videos in a DAM or Cloud Storage (Single Source of Truth)

Never rely on re-downloading videos from Instagram (using browser downloaders or scrapers) for cross-channel campaigns. Instagram compresses videos aggressively upon upload, degrades the bitrate, and removes metadata.

• Dedicated DAM / Enterprise Cloud: Use a Digital Asset Management platform (e.g., Bynder, Brandfolder, Adobe Experience Manager) or enterprise cloud storage (Google Drive, AWS S3, SharePoint).

• Store Raw Masters: Keep the high-resolution source video (.mp4 / .mov in 1080p/4K, 9:16 vertical and 1:1 square formats) in the DAM before it gets posted to Instagram.

• Naming & Tagging Taxonomy: Standardize naming conventions (e.g., YYYYMM_Campaign_Concept_Format_v01.mp4) and tag assets by platform, campaign, and rights clearance to eliminate duplicate uploads.

2. Hosting & Video Delivery for Marketing Cloud

Marketing Cloud Content Builder has file-size upload limits (typically 20 MB max for generic media files), which is too restrictive for high-quality video files.

• Host Externally on a CDN or Video Platform:
  • Host videos on a dedicated video streaming service (e.g., Vimeo Enterprise, Wistia, YouTube, or a custom CDN/CloudFront).
  • For CloudPages / Landing Pages: Embed the responsive player (<iframe> or HTML5 <video> tag pointing to the CDN URL). This ensures adaptive bitrate streaming across mobile and desktop without taxing Content Builder bandwidth.

3. How to Render Instagram Video in Marketing Cloud Emails

Direct video embedding (<video> tags) in email has notoriously spotty support across email clients (Outlook, Gmail, and Yahoo generally block or fail to render inline video players).

• The Pseudo-Video Pattern (Best Practice):
  1. Generate an animated GIF of the best 3–5 seconds from the Instagram video (optimized under 1–2 MB).
  2. Alternatively, create a high-res still thumbnail with a semi-transparent "Play Button" icon overlaid in the center.
  3. Upload that thumbnail/GIF into Content Builder.
  4. Hyperlink the image to your Marketing Cloud CloudPage, website landing page, or Instagram post where the full-quality video lives.

• This delivers near-100% email client compatibility, loads instantly, and drives high click-through rates.

Hi Lena, since both orgs are on the same laptop/browser and your Salesforce config in Org B genuinely looks correct, this is very likely a browser/Windows-side caching issue tied to the different origin (domain), not a Salesforce policy difference. A few things worth checking: 

1. Check Windows' own Passkey manager for a stale entry. Go to Windows Settings → Accounts → Passkeys (or Sign-in options → Passkeys). Look for any existing entry tied to Org B's domain — even a partial/failed registration attempt from earlier can cause Windows to skip the "create new" platform flow and jump straight to the cross-device/roaming flow instead. Delete any entry there for Org B's domain, then retry from Salesforce. 

2. Clear the browser's per-site permissions for Org B's domain. Chrome/Edge cache a "last used transport" preference per relying-party origin. In Chrome: Settings → Privacy and security → Site settings → search for Org B's domain → Clear data/reset permissions. This forces the browser to re-evaluate available authenticators instead of defaulting to whatever you (or a prior session) picked before. 

3. Confirm Org B's My Domain is fully deployed, not just the default login URL. WebAuthn ties credentials to the Relying Party ID (essentially your domain). If Org B is still on a default/undeployed domain or recently changed its My Domain, the RP ID Salesforce sends can differ from what you'd expect, which changes how the browser matches existing/available authenticators. 

4. Try a fully fresh browser profile/incognito window against Org B only, to rule out any extension (you mentioned Microsoft Authenticator extension is on in both — try disabling it just for this test) or cached state interfering specifically with that origin. 

5. As a last resort, use "Disconnect a passkey that isn't working" from your Salesforce personal settings (Advanced User Details → Built-In Authenticators → Del on any existing/broken entry for Org B), then try Add again from a clean state. 

If none of that breaks the loop, this is worth escalating to Salesforce Support directly with both orgs' IDs — a same-device, same-browser, config-identical discrepancy between two orgs isn't something Setup-level settings can explain, and Support can check server-side registration options (like exclude-credential lists) that aren't visible from the UI. 

Reference:

Hi Rashi,

Salesforce doesn't natively write files directly to an organization's shared network drive. A common approach is to use an external integration or middleware between Salesforce and the network location.

For example:

1. Schedule a Salesforce report/export or query the required records through the Salesforce API.
2. Have an integration service retrieve the data on a schedule.
3. The integration writes the generated CSV/file to the shared network drive for the bot to process.

Depending on your environment, this could be implemented using MuleSoft, an ETL/integration platform, or a small scheduled service that uses the Salesforce API. 

If the requirement is specifically for a scheduled Salesforce report export, rather than querying the data directly, the available options are different. Sharing the required file format, frequency, and whether middleware is already available would help determine the best approach. 

Hi George,

Could you please share which version of B2B Commerce for Visualforce you're using and what type of promotion functionality you're looking for? 

It would also help to know which Lightning promotion features you need to replicate on the Visualforce site. The available promotion capabilities can depend on the Commerce implementation and package/release version. 

If you can provide those details, someone may be able to confirm which promotion options are supported for your Visualforce implementation. 

 Hi Vinjul,

If Apex is returning the updated records but the child component is not reflecting them, the issue is likely with how the data is being passed from the parent to the child.

Could you please share the parent and child component code, especially:

• The combobox onchange handler
• The Apex call and how you assign the returned data
• The @api property used to pass data to the child
• The child component's HTML/JS where the records are displayed

Also, make sure you're assigning a new value to the property rather than modifying the existing array/object in place, so the component can detect the change. 

With the relevant code, we can identify exactly where the refresh is getting missed.

Hi @Scott Holmes

Yes, you can check the formula syntax directly in Flow Builder. Formula resources are created within the Flow, so you won't find their syntax in Object Manager.

To view the syntax:

1. Open your Flow in Flow Builder.
2. Go to the Manager tab.
3. Under Resources, select your Formula resource (Due in 7 Days / Due in 2 Days).
4. Open the formula to view or edit its syntax.

For example:

Due in 7 Days:

{!$Record.ActivityDate} = TODAY() + 7

Due in 2 Days:

{!$Record.ActivityDate} = TODAY() + 2

You can also review Salesforce's formula documentation for additional functions and syntax. 

Hope this helps!  

 If you find this response helpful, please mark it as the Accepted Answer, as it may also help other Trailblazers facing a similar issue. 😊 

Hi Piyush, 

1. You're right, mTLS is the wrong tool here. mTLS operates at the application/TLS layer after a TCP connection is already established — it proves identity to something that's already listening and accepting connections. If the vendor's firewall is dropping packets before that handshake even starts, no client cert changes that. mTLS solves "who is this," not "can this even reach me." 

2. Private Connect is AWS PrivateLink-based only, so it's natively usable when the target sits in an AWS VPC. Azure targets aren't natively supported — you'd need inter-cloud private peering (AWS↔Azure via ExpressRoute/Direct Connect + a transit arrangement) which Salesforce doesn't self-serve; that requires your account team and is a heavier lift. No public roadmap confirmation of native Azure PrivateLink support as of now. 

3. No native mechanism gives an Apex callout a narrower/tenant-specific egress identity beyond the published IP ranges — that's the actual gap you've identified. The published Hyperforce ranges are deliberately shared infrastructure-wide, not per-org, so it's a network-layer allowlist, not an identity boundary. There's no equivalent of "static NAT per org" for outbound Apex callouts today. 

4. Yes — a relay/gateway in front of the private service is the standard, recommended pattern here, and I'd recommend it. Put a lightweight reverse proxy (or MuleSoft Anypoint, or even a small managed API gateway) in a publicly reachable spot the vendor controls, with the vendor's actual private-network service sitting behind it. Salesforce calls the gateway over the public internet (allowlist-friendly, small surface), and the gateway — sitting inside the vendor's trusted network — forwards to the private endpoint. This gets you real identity-based control (API key, mTLS, OAuth — now actually meaningful since the gateway is an app-layer listener) instead of a shared-IP-range network allowlist, and it decouples you from Salesforce's outbound range changes entirely, since your callout target becomes a stable endpoint the vendor owns. This is what most orgs land on for exactly this scenario — it's a small piece of infra to own, but it's the durable fix. 

Reference: