What support is needed for the Salesforce integration post set-up?

Great questions @timcavey. Given your business is consumer-facing, there might be a ‘gotcha’ in the way that our integration works when it comes to Accounts → e.g. I think it’s likely that your Salesforce instance will be using Person Accounts, which we haven’t tested with this integration.

If you’re not familiar with Salesforce yourself, I think your CRM team would also need to take into account:

• How you as a community manager will be able to access the data
• How they can support you by building reports that are important to your business / desired outcomes with the community. You do have the option to get some reports out of the box (B2B-focused) but even these are just a starting point.

Has anyone that’s recently gone through this set up encountered unexpected, post integration?

Yes this has happened several times - mostly due to some kind of incompatibility with the way the Salesforce instance is set up. So it’s worth considering this as a risk when discussing with your CRM team.

Question originally posted as a reply to:

• Mass Update of Health Scorecard Comments

^ @timcavey really sorry, I need to reconsider the above response because I notice you’re talking about our latest Salesforce integration which is still in beta! Will come back to you today.

Given your business is consumer-facing, there might be a ‘gotcha’ in the way that our integration works when it comes to Accounts → e.g. I think it’s likely that your Salesforce instance will be using Person Accounts, which we haven’t tested with this integration.

This ‘gotcha’ still applies to our latest Salesforce integration which pulls data into inSided. I haven’t tested this integration with Person Accounts - if you can find out whether your Salesforce team have configured Person Accounts, then I’ll also check how the integration behaves with those enabled and whether it’s already supported.

Thanks @daniel.boon, I’ve asked this: *edit* I’m showing my CRM ignorance here but our CRM team have advised we don’t use ‘person accounts’, a contact is linked to a service account. 

It’s interested to hear the latest beta SF integrating is different to what existed before. Or is it simply that there’s now new ways to visualize that data in Insided Analytics? 

The beta Salesforce integration pulls data from Salesforce to inSided, rather than the other way round (which is what is already available). This enables us to help you report on more granular data that we don’t send to Salesforce (e.g. pageviews), and also it’s simpler to report on certain KPIs like % monthly active customers due to limitations with how Salesforce lets you report.

our CRM team have advised we don’t use ‘person accounts’, a contact is linked to a service account. 

I’m not sure what a service account is. The key thing to note is that the beta Salesforce integration looks at Accounts to determine whether a user is a customer or not. So maybe the right question given you’re not using Person Accounts is: “which fields on on which object(s) determine who is marked as an OVO customer?”

Also don’t worry about ‘CRM ignorance’ - CRM is a crazy world :).

Hi @daniel.boon if I were to tell you that according to a colleague, Salesforce isn’t the master of our customer data, and as a result usually we avoid creating dependencies on external services consuming data from it, and that all of the data we would require is available in BigQuery, as long as there’s a way to obtain it from there.

Would this be similar to any other Insided customers? What would you advise? 

Hmm… Developers never like to make things easy…

I think @timcavey you’ve just scored yourself a new Idea there! For something like this to work, you definitely won’t be able to hack together a quick bit of Custom HTML and plug that in. This would probably need a dedicated integration.

And to make that even more fun, while stuff like Salesforce would have consistent and easy to predict structures where it’s easy to figure out what kind of data might flow, BigQuery allows you to chuck your data into it using pretty much whatever structure you fancy and throw pretty much any data you can think of into the vault.

To make things even more fun still, there’d be no guarantee that one BigQuery dataset would have anywhere near the same structure as another. While one user might set it up really nicely and follow best practice, another might just dump stuff into the database completely randomly and pay little attention as to how they’re doing so. Mind you, I know of a CMS which does that… 

Is this a stealthy Insided dig, @Blastoise186?

Yep I don’t think any Big query > Insided integration would be simple. I’m keen to hear from @daniel.boon if you think the reasoning for avoiding the SF integration is justified though. Or if our approach is actually common and not an issue for this kind of integration…..

I’m pretty confident inSided doesn’t mess up the database that badly. But experience has told me that Drupal is absolutely horrible when it comes to database structure…

I’d be curious to see you guys try to hook up BigQuery to inSided though. I’ve got the popcorn ready. This could be good. 

Thanks both!