Skip to main content

​
What is a result object key?

A fetch action retrieves data from a third-party tool, such as a Healthie user or a list of available appointment slots. Every fetch action has an Object Name, and the data it returns is stored under that name for the rest of the workflow run. Any node downstream of the fetch action can read from it. The object name is the key you’ll see in the field picker and write in CEL expressions, so choose something short and descriptive, like healthie_user or open_slots.

​
Setting the object name

  1. Select the fetch action node and open its configuration panel.
  2. Enter a name in Object Name. Spaces become underscores and anything other than letters, numbers and underscores is dropped.
  3. Save the workflow.
Morf generates a default name from the application and action, such as healthie_v1_get_user_result_0. Renaming it early is worth the few seconds, because downstream nodes reference the name directly.
Object names must be unique within a workflow. Renaming an object name after downstream nodes reference it breaks those references, which will show as validation errors on the downstream nodes until you update them.

​
Using the result downstream

​
In the field picker

When configuring a destination action, fetch action or profile update below the fetch, the field picker shows a section for each upstream result, labelled with its object name. The trigger’s own fields stay under Payload Field. Pick a field from the result’s section and Morf writes the reference for you.

​
In CEL

Reference a field as a dotted path starting with the object name: The same expressions work in filter nodes, wait conditions and calculated values. The fields available under each object name are listed in the Result Object Field Details section of each fetch action’s page in the action library.

​
When the result might be missing

A fetch action’s result is only present if the node actually ran and succeeded. Two settings affect that.

​
Missing parameters

If the fetch action’s Advanced Settings set the missing-parameter behaviour to Skip node, the node is skipped when an input is missing and no result is produced. Morf then treats the result as optional downstream, and a plain reference like healthie_user.first_name fails on runs where the node was skipped. Use the optional form so the expression degrades gracefully: The field picker writes the optional form for you when the fetch node is configured this way. See the Custom JSON Payloads page for more on how optionals behave.

​
Failures

If the third-party call fails, downstream nodes on that branch don’t run, so they never see a missing result. To keep going after a failure, turn on Continue when this action fails in the node’s Advanced Settings and split the downstream path with parentActionErrored() as described in Error Branching. On the error branch the result is absent, so don’t reference it there.

​
Example: enrich a form response with Healthie data

  1. Trigger on a Formsort form response.
  2. Profile lookup to match the respondent to a Morf profile.
  3. Fetch action Healthie Get User, with object name healthie_user.
  4. Destination action Slack Send Message, with a message that uses both sources: the respondent’s first name from the form response, and their provider from healthie_user.provider_name.
Because the Slack node sits below the fetch, healthie_user appears in its field picker as its own section, alongside the form response’s fields under Payload Field.