Now available: App Connect 1.5.7

Thank you for this update. I did some further testing this morning with App Connect. I enabled server side logging, connected the BH API user, and did some test calling. The author of the call log is still showing only as the admin account and not the end user making the call. Is there another setting somewhere I should be changing?

​@sburton There shouldn’t be. Finding the right agent to associate a call with depends upon being able to find the user in Bullhorn via their email address. 

The other thing to check (just in case) is this:

To confirm, do we still need end users to log into the extension for server side logging to identify them as the author? Or does this update negate that?

Hi ​@ByrneReese ,

​@sburton and I are co-workers.  

I can confirm that the Admin (Me) is being logged as the "Author" in the note in Bullhorn.

I had ​@sburton log out of the extension and uninstall it to ensure I'm now controlling the server side logging for testing with the extension installed on my PC. I've signed into RC and applied the settings below which includes our BH API info (the same one we were previously using for Tenfold.) I then placed a call from one of my other team member's desk phone to a test user in BH. This team member's email address is correct in RC and because we use SSO using everyone's email address, I can assure you it's also correct in BH (matching what's in RC.) The author for our last call should have been this team member's name, but instead it was mine.

The call is being logged fine into BH, except for the "Author" being me instead of the actual caller. So the API connection should be fine in terms of the note getting to BH and writing to the record.

What mapping field is RC sending BH for the agent that's placing the call? Bullhorn is looking for the "corporateUsers" field, which translates internally as the ID of the user. So I'm wondering if the email address coming from RC is just not getting mapped correctly, so BH just uses the Admin as the Author?

This new feature should negate this most of the time. In subsequent releases we will expose tools for admins to map CRM users to RingCentral users to ensure a more reliable match. 

​@chris-phillips Let me first thank you for banging on this feature for us. I am going to share this report with the engineering team so that they can investigate properly. I will then get back to you.

Hi ​@chris-phillips 
> What mapping field is RC sending BH for the agent that's placing the call? 
We use email for the agent (a RC extension user) who is placing the call to match Bullhorn corporateUsers. 
We have a know issue that:
After this new version when the server side logging receive the agent’s call at first time, it will not update the note’s owner to corporate user. It will start syncing the agent’s email, then it will match and update the note owner after about 2 mins.  From second calls, it will work well without the delay.
 

Hi ​@chris-phillips Can you help to check if your auto call notes is assigned to agent successfully?
We found a setting cache issue for old users that will cause the email matching disabled. I have reset the setting cache.

​@ByrneReese and ​@Embbnux 

I used the same testing process this morning and I initially got the same result as yesterday, seeing myself as the Author/Agent instead of the actual person that placed the call.

However, seeing the caching issue that ​@Embbnux stumbled upon last night, I decided to try it again (after the suggested ~2mins) and it worked as expected!  So we’re good with that test.

However, we did find another protentional problem.  Using the same candidate record as above (lets call him Jimmy Test), we changed his cell phone number (xxx-xxx-1234) to a different number (xxx-xxx-7890).  We then took another candidate record (Steve Test) and changed his phone number to Jimmy Test’s original number of xxx-xxx-1234.  We placed another test call following the exact same successful procedure above, calling the same phone number xxx-xxx-1234, which should have created a note on Steve Test’s record since he now has that number.  It did not.  It made the note on Jimmy Test’s record.

Now, I can’t say that this situation where someone changes cell phone numbers and someone else in our system gets the exact same number that someone else had previously is going to be pretty rare, but this scenario could happen.

We did make a third test, again using the same successful setup as above, but this time calling Jimmy Test’s new number of xxx-xxx-7890.  This test did work as expected wtih the note being created on Jimmy’s record.  

​@chris-phillips Thank you for this report. This is not surprising on some level, but definitely not the desired behavior. We may want to issue guidance to developers that their adapters should do a findContact call as a sanity check prior to logging a call. 

FWIW - when a phone number changes knowingly, you can always go to “Refresh contact” in the phone list to force a re-lookup and mapping of that phone number to a contact record.