For anyone else using the Salesforce Managed Package to sync between Ti and Salesforce, we are seeing that learners that are made on Ti, Ti is trying to sync those learners to contacts that don’t exist in Salesforce.
I’m curious if anyone else is dealing with this and what your solution is? Our CRM team doesn’t want to manage the false users constantly after every sync. How is everyone else managing it?
Our IT team had a hard time with the syncing piece, sending over thousands of rows of data per day. I don’t have all the details, but they ended up turning the sync off. We can create users from SF into TI by pushing them through, but no syncing of data after that. Our admin users didn’t notice.
We’re working through this now and have run into multiple issues due to the odd way the managed package is implemented. Ultimately, it looks like we’re going to setup a “catch all” SF account for the sync job to drop users into that don’t have an existing contact match in SFDC. Also, if a single user in TI has a value populated for SF Contact ID that is incorrect or improper format it will not process the entire sync. It could be the last user in the list of thousands but it will not sync the thousands and drop the last user it, it will fail the entire sync.
We are considering using the connection to just send completion data for courses and live sessions to Salesforce. I know this post is 4 months ago, but I wanted to check and see if you had solved these issues? I don’t want to move on this if it is more trouble than it is worth.
We’ve actually had a good experience with the SF managed package. We do have a catch-all account to catch users who don’t have SF accounts yet, so never had Ti trying to connect people to contacts that don’t exist. And for us, the number of unknown contacts who then need to be added to an existing/new account has been very manageable.
The trickiest/most challenging part is that we match on email and sometimes people use different emails in different places, so the same person ends up with multiple contact accounts that we merge. But we are streamlining our onboarding process to shrink this issue and hope that + SSO will make the accidental creation of duplicate accounts nearly non-existent.
Hi everyone,
We previously had the Thought Industries Managed Package connected, but ultimately disabled the integration after it started creating a large number of unassociated contacts in Salesforce (no AccountId). We had to do a significant cleanup effort and haven’t reconnected since.
I’m now revisiting whether it’s possible to reinstall the package and configure it more effectively, ideally so that contacts are created and matched accurately to the correct Salesforce account.
A few questions for those who’ve had success getting this right:
Has anyone been able to configure account matching in a way that reliably ties contacts to the correct account, rather than defaulting to unassociated records?
For those using a catch-all account setup, has that proven manageable, or what are some pitfalls of the process?
Were there any specific field mappings or pre-matching steps that made the integration cleaner?
Appreciate any insights you can share!
Hi
I’m wondering if our use case might be slightly different from yours. Most people who join our learning center already exist in our Salesforce, so we match to the SF contact record based on email address (and their SF contact record is usually already matched to an SF account record). Therefore, the only time we have a non-match that goes to our SF catch-all account is when the person doesn’t yet exist in Salesforce or uses a different email for the learning center.
I checked with my Salesforce team, and they said we didn’t do any special mapping. We followed the standard set-up, including the catch-all account.
The biggest hassle we deal with regularly is needing to merge accounts. For example, a person will register for the learning center with one email address before they have access to the app, register for the app using their standard work email, and then SSO from the app to the learning center. So now they have two STLC accounts and sometimes have completed different courses in each. In that case, we need to decide on which account they’ll keep (usually the work email address, so they can SSO from the app) and merge the accounts. In our case, it’s been manageable, but it is a little extra work and a wasted license when one person ends up using two spots.
Where we have done some finessing is with sublicenses. In one of our panoramas, we have sublicenses by client company, and the client sometimes have 2-4 different domains. All those users SSO into the learning center from the app, so our engineers set up the SSO mapping to account for the different options, and reliably direct people to the correct sub-license. That isn’t directly applicable to SF, but I wonder if you also group users by sublicenses, if that may create an opportunity for easier SF matching (as in, if they are in this sublicense, add them to this account). I have no idea, just spit-balling a bit.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.