Hi there,

I’m not sure what you’re trying to do. Can you give some more detail?

Thanks!

@shalgrim 
I have a trigger that hydrates information from a parent record based on its id. The fields in the parent record come in like `field_557` instead of `birthday` for example. I would like it so that when users map these fields in future steps, it displays as `birthday` instead of `field_557`. I can get the outputFields to work for the record, but I cannot get it to function for the hydrated values. Is this possible and I’m just missing something? Or will the output fields not work on hydrated values?

Hm, I have several follow-up questions:

1. “trigger that hydrates information from a parent record” … So, what record triggers the trigger? Is it the “parent” type? I.e., your trigger is New Parent? And then you go get additional information about that Parent, like about its Children? For example, you want to populate a list of its Children, their names, ages, favorite toys, etc.?
2. “The fields in the parent record come in like `field_557` instead of `birthday`” … So on the Parent record there is a field called `field_557`. And it comes through in the initial hook or the initial poll? (Is it a hook or a polling trigger?) And how do you convert it from `field_557` to `birthday`? You call an API endpoint that does that translation?

If that’s the case, as long as what you’re returning removes field_557 and replaces it with birthday it should be working. But I might well be misunderstanding something.

A few more resources, which you might already know about, but let’s give it a try just in case:

Hydration documentation:

• https://platform.zapier.com/cli_tutorials/hydration
• https://platform.zapier.com/cli_docs/docs#dehydration

And I’ll add that you might also consider reaching out to platform support by filling out the form at https://developer.zapier.com/contact while you’re logged in as the account you’re using to develop the app.

Hope that helps...let me know how I’m doing on understanding the problem or let me know if you have any more questions!

I’m afraid you misunderstood, but I appreciate the attempt.

The trigger is a child record. When a new child record is found, I then hydrate the parent record along with it. When I generate the output fields for the child record, they are successful. The subsequent steps will replace `field_###` with `label` in the child record. However, when I go to use output labels on the hydrated parent record, the fields do not seem to work.

Ah, thanks for understanding.

Okay, so I’ll do some restating again to try to make sure we’re on the same page.

You’ve got a new trigger, something like New Child, that triggers every time there’s a new child record. That child record probably has some field like `parent_id` in it.

And within the trigger you make an additional call to something like the `…/parent/{id}` endpoint to get more information about the parent (i.e., hydrate it). And that’s what you’re referring to as hydration, right? You’re not using any of the de/hydrate tooling whose documentation I linked to in my last reply?

And when you send the data of this trigger to downstream steps you’re returning something like:

{

    ‘type’: ‘child’,

    ‘name’: ‘Junior’,

    ‘age’: 12,

    ‘birthday’: ‘2010-12-01’,

    ‘parent’: {

        ‘name’: ‘Senior’,

        ‘age’: 42

        ‘birthday’: ‘1980-12-01’

    }

}

But instead of `birthday` you’re seeing `field_557`.

Some questions, then:

1. What do I have right and wrong about the above?
2. Is it the call to the `…/parent/{id}` endpoint that is returning field names like `field_557`?
3. How does one, in a non-Zapier context, translate from `field_557` to `birthday`?
4. Have you tried doing something in your code like:

response.data`‘birthday’] = response.datav‘field_557’]

delete response.datae‘field_557’]

return response.data;

I am indeed using the dehydrate method.
`record.parent_record = z.dehydrate(hydrators.hydrateParentRecord, {parent_id: record.parent_id});`

1. You are understanding the general gist now, yes.
2. The endpoint `…/parent/{id}` is returning the field names like `field_557` that is correct.
3. Not sure what you’re asking there.
4. I do understand that that is a possibility, and I could implement it that way, but I am attempting to use the outputField functionality, as I already have a few users on the integration and doing what you suggested would break mapping in future steps and thus interrupt their zaps. I am attempting to avoid this. outputFields would get allow me to not break their zaps but allow future users to be able to see the human readable labels in the future.

I have a function that is calling something like `…/parent/fields` which gets me a list of fields. I actually do the same for child fields `…/child/fields`. The dynamic generation of the child fields works but its not taking on the parent fields that get dehydrated/hydrated later. My question is, how do I employ the outputField functionality to work for fields that have been dehydrated/hydrated by the z.dehydrate() method? And by outputFields I am referring to  `module.exports.operation.outputFields`.

For question 3, what I’m asking is, if the API returns a field whose name is “field_557,” how would somebody translate that to “birthday”?

I already have a few users on the integration and doing what you suggested would break mapping in future steps and thus interrupt their zaps

Do you mean that you have users who have already mapped “field_557” in subsequent steps and you don’t want to break those mappings? That makes sense, I’m just asking to make sure I’m on the same page. And if you wanted not to break Zaps, you could add in the response.data ‘birthday’] = response.datat‘field_557’] and then just not add the delete response.data ‘field_557’] line.

Next, I’m not sure what you mean by using or employing “the outputField functionality” or how “outputFields would allow you to not break their Zaps.” What is it that you’re currently doing in outputFields and what behavior would you expect to happen there? The way output fields show up in the editor is just with a pretty key (e.g., “Field 557”) and the value (e.g., “1980-12-01”) that is in the selected sample. I don’t know of anything in outputFields that would translate field_557 to birthday.