Hi @ddpancratz 

Good question.

If this was a temporary hiccup/glitch, then it may not be worth worrying about.

If it is persistent/consistent, then you should open a ticket to report a possible bug with Zapier Support: https://zapier.com/app/get-help

Hey @ddpancratz 

I’m currently running into the exact same issue. I just opened up a ticket with the support. 

This happened to me already about 2 weeks ago but I didn’t worry about it for long since I only needed the ID value which is the only thing it returns in “clear".
I have found some documentation on this hydrate/dehydrate topic, but it’s all connected to Git/code etc and I’m just in the regular “pretty Editor" where I don’t see any options to fix this.
It also said that it would “dehydrate" this file whenever it was needed later in the Zap. For me, this data is supposed to be used in the next step but it’s simply not accessible.

May I ask what Object this occurs on for you? For whatever reason, Opportunity fields are returned normally, but fields of the User Object are returned hydrated.

Hope this is being solved soon since we now have to manually recreate all this!

Hi @ddpancratz,

We’ve seen some users run into this intermittently in the past. Can I ask, is this a shared Zap? I.e., do other users have access to the Zap? Is it using somebody else’s authentication? We have a hypothesis that this happens when the Zap run depends on the authentication of the person using it.

I have a potential workaround, though as of yet we haven’t heard confirmation that this does or doesn’t work. Can you try re-creating the step using the Zap owner’s account?

Let me know if that helps

@shalgrim 

• Shared Zap: Yes
• Shared App Connection: Yes 

@stellag It’s a “Community Member” object for the integration with Insided, our community vendor (same platform as this community )

I managed to get it back to work!

For me this was also a shared Zap, owned by someone else and also all the connections to the account of that person. Ever since I edited the Zap it wasn’t working anymore. 

Now I assigned myself as the owner of the Zap (still with the other persons integrations), triggered it and it returned normal values again!

So I guess not the integration accounts but the one editing the Zap might be the issue. 
It would be nice to have this fixed, in the end it should act the same way, no matter who edits it from the people you share it with. 

Thank you for your quick help @shalgrim !

@stellag Interesting!

I went to try that, but I realize that it’s a new-ish Zap that I created in a shared folder that I also created. 

The only thing shared are the credentials for authenticating in Salesforce, which were set up by my colleague. 

@shalgrim any recommendations? 

I’d recommend either creating your own authentication or change the owner of the Zap to the owner of that authentication

An update on this:

I took @shalgrim’s advice and changed the owner of the Zap to the owner of the authentication. Unfortunately, that did not solve the issues. This Zap runs daily and has persisted for the past 2 weeks. 

Sounds like I’ll need to open a support ticket. 

I haven’t tried setting up my own authorization, but I’d rather use the existing one, as it is tied to an Salesforce admin user (vs my limited permissions)

I solved this with the help of support. 

First, it’s a known bug they’re working on. 

But here was how we solved it: 

We think the bug is happening when the steps in your Zap are "owned" by different individuals.  Of course, it is perfectly valid for this to happen since we allow for the sharing of your Zap in shared folders.  This means that if another member of your Team edits a step in the Zap that you created that there will be a mixture of owners for the individual steps.  We do not expose the ownership of steps in the user interface because it shouldn't matter.  However, in this case, with the find step you are using it does matter because of the bug.
 
The easiest thing to do to make sure that all the steps are "owned" by the same user is to duplicate the Zap.  When you do this, all steps will be owned by you.

It wasn’t that the authentication / App connection or Zap owner mattered, it was that the step owner mattered. This step had been set up a year ago by my colleague. When I copied the full Zap, it made me as the owner of each step and resolved the issue. 

But, like I mentioned, Zapier knows it’s a bug and they’re working on addressing it. 

I can appreciate that this is a pretty convoluted way of doing things but I wanted to provide the explanation in case this happens again before the bug is fixed so you have a way forward.

Thanks, @ everyone on this thread for your help. And also to Zapier support for an A+ first support ticket experience.