Feed

Give this permission set to service resource user  

I hit the same windshield. When I tried to retrieve all WorkflowOutboundMessage metadata, I got  

 sf project retrieve start --metadata WorkflowOutboundMessage 

 ────────────── Retrieving Metadata ────────────── 

 Retrieving v61.0 metadata from [source org ] using the v64.0 SOAP API 

 ✔ Preparing retrieve request 10ms 

 ✔ Sending request to org 243ms 

 ✔ Waiting for the org to respond 4.88s 

 ✔ Done 0ms 

 Status: Succeeded 

 Elapsed Time: 5.13s 

But just as a lark, I decide to try grabbing just 

of the messages, and... 

sf project retrieve start --metadata WorkflowOutboundMessage:[API Name of outbound message] 

────────────── Retrieving Metadata ────────────── 

Retrieving v61.0 metadata from [source org] using the v64.0 SOAP API 

✔ Preparing retrieve request 13ms 

✔ Sending request to org 243ms 

✔ Waiting for the org to respond 909ms 

✔ Done 0ms 

Status: Succeeded 

Elapsed Time: 1.16s 

Retrieved Source 

│ State   │ Name                   │ Type     │ Path                                                                      │ 

│ Created │ [Related sObject] │ Workflow │ force-app\main\default\workflows\[Related sObject].workflow-meta.xml │ 

This didn't actually retrieve the 

, but when I look in the metadata I see  

<outboundMessages> 

      ...all the stuff from the outbound message I just retrieved... 

</outboundMessages> 

But herein lies the problem. If I do that again with the 

message for the same object, it overwrites the first one.  

So. 

I try the same retrieve with only the sObject name, and it can't find it because it doesn't exist. Fair enough, there's no Outbound Message that has that name, so I try  

sf project retrieve start --metadata Workflow:[Relevant sObject] 

That works, as far as it goes, but it retrieves

approval processes for this object...). Somehow the approval processes got into the package, but he workflows didn't? I suppose they were already deployed everywhere so there wasn't a dependency issue, and nobody ever noticed they were missing ('cause they weren't actually missing, were they?). 

So in theory, all I would have to do is import the entire workflow for each affected object, and I'd get everything. I'm not sure how anxious I am to do that on some of these, since who knows what other dependencies that would create, but now I know where they live, I can attack that as a separate story, use the change set to deploy what I need and circle back to it "in my spare time". 

If that's not workable, or if you just need to update the urls on all of the messages in place, you

 be able retrieve the workflow, update the UR;ls in the outbound message elements and then deploy it back to the org, not retaining a local version if you're worried about a depedency issue. Just put it on a separate branch that never gets packaged. 

Hi @Altamash Qureshi

Please check out the following url: 

Thanks

Even if it feels like you did all the steps right, this particular error usually points to the filter settings inside your Reservation 1 Flow element not matching exactly what Trailhead expects. It’s super picky about it. 

When you go back into the Reservation 1 Flow element in your Data Cloud setup, double-check these:

• Make sure the filter logic matches exactly. For example, if the step says Equals or Contains, it really can’t be something similar to Starts with.
• Watch out for extra spaces, even a stray space in a field value or label can throw the whole thing off.
• Check that you’re filtering on the correct field (sometimes people pick the wrong Reservation object field or attribute).

Another tip: I once found that re-saving the filter after clearing it and re-adding the condition actually worked. I guess the playground sometimes remembers an older state. 

If all else fails, try refreshing your playground session or even spinning up a new one, sometimes weird caching happens.

Hi, 

I went through this exact process a couple of years ago when my company rebranded. It’s a big project, but totally manageable if you map it out carefully. Here are a few lessons we learned (and some surprises we ran into): 

First, yes, setting up the new tracker domain is step one. We had to work closely with IT and DNS to get the CNAME set up properly before switching it in Pardot (now Account Engagement). 

What surprised us:

• Old URLs were everywhere, landing pages, email templates, forms, and images all needed manual updates. We actually missed a few nurture emails and had to fix them fast after people clicked broken links.
• We forgot about SSL for the new tracker domain at first, which delayed us. Make sure you set that up early.
• Any custom redirects in Pardot need to be recreated for the new domain, or you’ll get 404 errors.
• Engagement Studio programs often have links or assets tied to the old domain, easy to overlook.

What helped us

• We ran the old and new domains side by side for a bit. This gave us time to update things gradually without breaking live links.
• Doing a full content audit before starting saved us a lot of headaches.
• We kept the sales team in the loop early since they often share marketing links.

Last thing: if you use dynamic content or personalization, double-check for old logos or brand references. 

What @Dodi Friedenberg

said. While this description is not a match for the exact criteria in that Known Issue, it seems clear that there was an issue introduced in Summer '25 related to Naming.  

The good news (hopefully) is that there is a fix in process, and it appears they are targeting it for a patch release, so folks won't have to wait until Winter '26 (next release).  

But I'm not entirely convinced this issue will be resolved in the code they're working on.

Hi @Nuriye Kahraman

You cannot change profile of a user directly from flow. 

but you can change profile of a user from Apex. you can add your custom logic in apex file for assigning profile to a user. 

few things to consider: user must be active and not an admin user

Hi @Genna Wilson

o resolve the issue with the missing ‘Technical Skills’ field section on the Technical Position

page in the Trailhead playground, please follow these steps:  

1. Go to the Technical Position record page (open any existing record).
2. Click the gear icon at the top right and choose "Edit Page" to open the Lightning App Builder.
3. In the Lightning App Builder, look for the ‘Technical Skills’ section in the components or fields pane.
4. If it's not already added, drag and drop the section onto the page layout where appropriate.
5. Click "Save" and then "Activate" the page if prompted.
6. Go back to the record page and refresh the page. The ‘Technical Skills’ field section should now be visible.

 Thanks

Hi, @Maria Esther Mora-Rey Goetsch

In that case try to connect with Salesforce Help Team.

Sincerely, 

Mykhailo Vdovychenko 

Bringing Cloud Excellence with IBVCLOUD OÜ