Use attached call data created in CFD in CRM

[JonTheITGuy]

Is it possible to attach call data in a CFD and then pull that data in the reportcall of a crm integration? Use case is that we need a crm integration that I have created and works fine, except that it creates a ticket in the CRM for every inbound call. Trying to figure out a way to only create a ticket in the CRM for certain ring groups or extensions. I have created the CFD and it works just like the CRM to get contact and create ticket for the correct ring groups. I just do not have a way to get the call data when the call ends and update the ticket with tthe url for the call recording. All we need for now until we can get a transcription setup going. Is this possible or does anyone have any suggestions on how to get the system to only create tickets for certain extensions/ring groups and then update ticket info with call journaling values? Any help would be appreciated and thanks for all info in the forums, its helped me a lot setting this up.

 

[JonTheITGuy]

Call Flow is as such:
1. external call comes into IVR
2. call is Transferred to CFD from IVR menu
3. call goes through call flow
4. call is transferred to agent
5. call ends and hopefully call journaling is completed.

It was working before we updated to build 6. The only other thing my boss did was turn off ipv6. Didn't think this could be the issue but at this point I feel I need to re-evaluate everything.

Also, in the lookup scenario, you also need to provide at least 1 phone number that matches the number looked up, otherwise the match is ignored.

Will using the session.ani variable meet this condition? Or do I need to set the session.ani into a variable and use that?

 

[Evolute IT]

Will using the session.ani variable meet this condition? Or do I need to set the session.ani into a variable and use that?

session.ani should work if you set it in PhoneBusiness/PhoneHome/PhoneMobile/etc. Any of them. There must be at least one.

 

[JonTheITGuy]

Its got to be something I'm not setting correctly. If I don't need a matching scenario in my CRM and I attach "public_crm_contact" with at least "FirstName", "LastName", "PhoneBusiness", "ContactUrl", and "ContactRawData", then it should at least try the call journaling. Its not, so then I have some issue with attaching data to the call. Do you generally set more than "public_crm_contact" property. Only other thing I'm attaching is the "public_lookup_displayname_override" like edossantos states in that post linked earlier.

 

[Evolute IT]

Its got to be something I'm not setting correctly. If I don't need a matching scenario in my CRM and I attach "public_crm_contact" with at least "FirstName", "LastName", "PhoneBusiness", "ContactUrl", and "ContactRawData", then it should at least try the call journaling. Its not, so then I have some issue with attaching data to the call. Do you generally set more than "public_crm_contact" property. Only other thing I'm attaching is the "public_lookup_displayname_override" like edossantos states in that post linked earlier.

Usually the public_crm_contact is enough. We use this on many many many projects.

Just for fun, could you send me your callflow by DM? I'd be curious to check it upon my return in the office.

 

[edossantos_sipcaller]

The property public_lookup_displayname_override is to set the customer name that you want to be shown in the Web Client. But it will not affect Call Journaling.

To investigate this further, you might need to create a service that logs all the changes to the attached call data for that call, I think that's the only way to really know why things are changing.... But that can't be done from the CFD, you would need to create a service using the Call Control API...

 

[JonTheITGuy]

Are there certain scenarios in the CRM that must be there for this to work besides ReportCall? I have no matching scenario, but I do have an Auth Scenario. If I enter a matching scenario the CRM will run correctly and CFD will update everything but ContactRawData. Just want to make sure I'm not missing something simple.

 

[edossantos_sipcaller]

Maybe 3CX is caching the ContactRawData somewhere once returned from the CRM. This was not the case in the past, but maybe a recent change added this.... I can see that the 3CX database now has a table containing CRM cached data, so it might not be possible anymore to change this information from the CFD once it was returned by the CRM. Another option you have is not providing the matching scenario in the CRM, and then run this lookup using the REST API directly from the CFD app. This way the information will only be added by the CFD, not updated.

 

[JonTheITGuy]

That's how I initially had it setup. CRM only had ReportCall and following scenarios. I used rest to get contact and create a ticket in the dealer supplied ticketing system in the CFD. The only thing the CRM did was update the ticket with the agent and transcription. I saw all the cached stuffed in the logs and have been wondering about that, but havent found anything. When the Auth scenario sets Bearer and stuff, is that part of setting the CRM data thats caching? Can I set the ContactRawData with an access token or do you know if there is a size limit on the ContactRawData?

 

[Evolute IT]

@IliasL_3CX can you confirm if the ReportCall handling has changed?

This would break many of our custom integrations...

 

[edossantos_sipcaller]

The Auth scenario is just something to get the token that will be used in subsequent requests, but has nothing to do with the cached data. Having it or not will not change anything. Indeed, some standard CRM integrations require that Auth scenario, and others don't, so it doesn't really make a difference.

The ContactRawData in previous versions was only kept in memory. If now this has to be stored in the 3CX database, then it's probably being done by the 3CX CRM engine, and if you try to do this from the CFD app you will be missing that part. That would explain why you see all the properties updated, except by this one. But I can't really tell, only 3CX can confirm if this has changed in this way...

 

[JonTheITGuy]

Thanks for all the info and answers. Really appreciate it. Hopefully we will hear something from them that this is still an option. For awhile there thought maybe I was just exploiting a bug and they fixed it, but seems like thats the way it was for a long time. Still might be, but I feel I've tried every iteration of attaching the json data I could think of. Glad they fixed the Call Flow Designer so I didnt have to change the transferring extension variable in the script everytime I updated it.

 

[IliasL_3CX]

@ConceptsWeb , @JonTheITGuy , Yes indeed there were many redesigns in U6 with regards to cdrs/reporting. In U6 this information is stored in the database as Ernesto mentioned. Thus you can readjust the CFD apps in order to read from the database, manipulate the data required, which then will be send for call journaling. I would caution you to be careful when editing any values in the database as in case of incorrect handling you may experience other unexpected results

 

[JonTheITGuy]

But doing this is highly frowned upon and could make our instance of 3cx unsupported, correct?

 

[edossantos_sipcaller]

But doing this is highly frowned upon and could make our instance of 3cx unsupported, correct?

Yes, just be very careful, as it is the only way.

 

[Evolute IT]

Thus you can readjust the CFD apps in order to read from the database, manipulate the data required, which then will be send for call journaling. I would caution you to be careful when editing any values in the database as in case of incorrect handling you may experience other unexpected results

How would you recommend doing this from a call script to just push the data like we used to? Is there a way to identify the CDR row ID or something like that from the Call Script/CFD to know which row to update?

 

[VoIPTools]

I have to say, I have to pause when I see someone from 3CX suggesting that a customer directly access the PostgreSQL database, let alone make changes to the data. The "thou shall not touch" commandment has been consistent, and aggressively enforced for the nearly 20 years I have been working with 3CX. When I was working in 3CX Support, the internal message from 3CX was very clear -- DO NOT DO IT EVER.

But I noticed that the new Grafana integration requires a small change to the PostgreSQL configuration .ini file -- something I was expressly forbidden to do by 3CX with some pretty severe consequences if we did. So maybe 3CX has changed their policy?????!!!! Frankly, I would be pretty shocked by such a change in policy, and honestly, I thought the reasons for the no-touch policy were grounded in some very solid logic. I personally would think having customers/partners making changes to the production data would be a nightmare for 3CX Support.

What I know is that you have two of the best people I know, when it comes to implementing CRM integrations, answering your questions (@ConceptsWeb and @edossantos_sipcaller). If anyone outside of 3CX knows the answer one of these two will. This is not an area of my expertise (in comparison), so I will defer to their guidance.

If all else fails, you can change approach as suggested by @edossantos_sipcaller and create a service that monitors events using the original Call Control API, and not rely on the existing CRM integration approach, but that is a lot of work so let us hope they can get you the answer.

 

[KyriacosS_3CX]

But I noticed that the new Grafana integration requires a small change to the PostgreSQL configuration .ini file

Hello,

Is this in reference to the instructions found in: https://www.3cx.com/docs/postgresql-configuration/

It should be noted that those are for the installation of an external PostgreSQL instance to offload data to, no changes are done on the PBX itself.

 

[VoIPTools]

Thank you for the clarification. I was skimming the instructions weeks ago and my brain did not make the distinction between the 3CX PostgreSQL and the replicated PostgreSQL. Thanks for the clarification and I now I can sleep knowing the my world (at least on this point) has not changed.

Still, how does suggesting someone start making changes to production 3CX data fit into my historical world view? Perhaps I misunderstood the other half of the conversation as well?

 

[KyriacosS_3CX]

HI @VoIPTools ,

I get how Ilias's comment could be read to mean messing with the DB is an option, but just to make sure your worldview is restored , let's break it down:

Thus you can readjust the CFD apps in order to read from the database, manipulate the data required, which then will be send for call journaling.

"Use the CFD to gather data in the normal CFD way, read only, massage it as needed and send it out to the external call journaling."

I would caution you to be careful when editing any values in the database as in case of incorrect handling you may experience other unexpected results

"Be warned if you try to edit anything directly in the DB, things might break in many mysterious ways, don't do it."

So all is well, no messing with the DB and don't use STUN are still the two main commandments !

 

[VoIPTools]

Faith Restored. Thank you.