UnofficialSF Discussion

Thank you @Ashapura Softech INC

I rolled through your checklist: 

Yep, I'm using the correct install link - for Test 

Yep, the 04t ID is the same version that I installed elsewhere last month 

The sandbox I'm attempting to install it into is on Winter '27 

This is the version of the package I'm trying to install: 04t5G0000043xtAQAQ 

@Richard Horton the recipe is the right shape if the goal is a REST call from Flow without Apex. A few edges are where these guides usually go quiet.

A record-triggered flow can't make the callout on the path that runs immediately. The HTTP Callout has to sit on an asynchronous path. Flow Builder warns you if you drop a callout on the immediate path before that toggle is on. A screen flow, or an autolaunched flow a screen calls, can call out in the same transaction. The record-triggered one can't.

Auth belongs on an external credential and a named credential, not in the flow. The named credential holds the URL, the external credential holds the protocol and the principal, and a permission set has to grant the running user access to that principal. If the user running the flow doesn't have it, the callout fails even when the action looks fine in the builder. I'd stick to the current named credential model rather than a legacy one.

The path, the headers, and the sample response you paste when you create the action get frozen into an external service. If the API adds a field or changes an error body, you rebuild that action. A fault path matters, because a 401 or a timeout otherwise just fails the interview. And if the body isn't a flat JSON object, the sample response is the part I'd spell out. That's where people get stuck when they point the same pattern at a different API.

Bulk is the other one. A record-triggered flow runs an interview per record, so a mass update can fire a lot of callouts. Worth saying what you expect people to do when a couple hundred records save at once. I didn't walk every line of the IndieML repo. These are the spots I'd want covered.

When you type "Default" you are passing the literal string of "Default" to the quickchoice.  

There is no label associated with "Default" which is why it appears blank in the UI,but then tries to save as "Default". 

Check out the documentation on unofficialsf. Notice how they are passing in variables from the flow 

Hey All, 

I heard back from Salesforce. The issue here is as follows (per Salesforce support):

The ers_Datatable Lightning component renders lookup fields as clickable links by enriching the row data through its Apex controller (ers_DatatableController.getReturnResults). Inside getColumnData, lookup fields are only added to the lookupFields collection when the running user has Edit (Updateable) access to the field:
when 'REFERENCE' {
if (dfr.isUpdateable()) {
lookupFields.add(fieldName);
}
}

In other words, the documentation on the UnofficialSF website is might need some slight wording adjustment. That is, the user in question needs EDIT permissions on the field itself, not the just the object that the datatable is listing records for. 

In case it helps anyone, I compared to the standard/out of the box datatable links to related records feature due in the next update and the "Edit" permission is not required. I do think the standard datatable component is still lacking a large number of features, though.

After a few hours of trial & error, I got this to work. YAY!!! 

Since this flow action actually creates a deployment, checking in Deployment Status helps figure out what's wrong. 

Since I only have one single record in my custom metadata type, I need to update the AccountID field with the record ID of the account the user is viewing. 

Attaching screenshots of what I ended up doing in Flow.