Jenna Z.

Looks like it's showing up as Owner ID. You'll probably have to run a second lookup to User to get a name if you don't already have that as a custom formula field on the SF account

Hi Beau M. - that "object field(s)" value is the unique identifier of the account you're looking up in Salesforce, and then you provide the value to look up. So for example, if you have the Salesforce ID in your Clay table already, you'd use that; if it's a list of companies from another source and you don't have the Salesforce IDs but you have something that's relatively unique you could match against like "Domain", you'd use that. You're basically telling Clay which SF account to match against. Once the action runs, you'll see the full list of fields available for each pulled Account and can map Account Owner to it's own column

🎉 this is awesome, tysm!

🙏 thank you both!

Malik I think you're going to run into the same issue - sending to Clay as JSON, receiving a text response from Clay on successful runs that SFDC can't handle. I didn't find a solution, and everything works fine besides the constant error messages. I just send them to a filtered folder and ignore. Following in case anything's changed or you come up with something, though!

ah, seems like TeamLink Extend is what we need since we only have 10 Sales Nav full licenses and want to add all employees' connections (but have 1k extend licenses available I never noticed). thank you for the link and for being more helpful than LinkedIn Support, who told me it wasn't possible!

After some more research it looks like it's possible with PhantomBuster, but not the Phantom I've seen recommended elsewhere (LinkedIn Connections Export, which also uses cookies and is just for the running user's connections) - using this one instead: LinkedIn Search Export Phantom. Going to try this out today but sharing here in case anyone's stuck trying to do the same thing (Sagar M.)!

Hi! It took a while to confirm this with Salesforce Support, but I have confirmed that there are no current options for accepting a response that's not in an application/json format 🙃 This means that while my webhook POST callout to my Clay table is successful, I still get an error from Salesforce every time it runs, and they've confirmed there's no workaround to even ignore a response that's not JSON formatted. Because I imagine I'm not the only customer to try to implement Salesforce > Clay webhooks, sharing that info here to see if there's any way to add response format selection as a feature while we're waiting on SFDC to get its act together 😊 Even though I have a CRM integration included on my current plan, the use case for the webhook here is to update records in real time for our inbound process, so it's not a matter of upgrading my subscription. Thanks, lmk if you have other questions!