Feed

Here's how you can achieve your goal of retrieving a specific child record from API.  

1. Use the query resource with a subquery:

• SELECT Id, Name FROM Contact WHERE Id = 'ContactId': This is the main query to select the parent Contact record.
• (SELECT Id, Name FROM CustomChildObject__r WHERE Name LIKE '2025 Renewal%'): This is the subquery that retrieves the child records from the CustomChildObject__r relationship where the Name matches '2025 Renewal%'.

/services/data/vXX.X/query?q=SELECT+Id%2C+Name+FROM+Contact+WHERE+Id+%3D+%27ContactId%27+AND+%28SELECT+Id%2C+Name+FROM+CustomChildObject__r+WHERE+Name+LIKE+%272025+Renewal%25%27%29

2. User Interface API with filtering (if applicable): 

• /ui-api/records/ContactId/child-relationships/CustomChildObject__r: This part retrieves the child records for the specified Contact.
• ?q=Name+LIKE+'2025+Renewal%25': The q parameter is used to apply a filter based on the Name field. This will depend on whether the UI API endpoint supports filtering related records this way. 

/services/data/vXX.X/ui-api/records/ContactId/child-relationships/CustomChildObject__r?q=Name+LIKE+'2025+Renewal%25'

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.