Caller Id

0 views
Skip to first unread message
Message has been deleted

Bernd Manison

unread,
Jul 9, 2024, 12:00:34 PM7/9/24
to mondcaconcoe

I have followed all the instructions to set up caller id for HubSpot contact on both my iPhone (13) and on the HS app, and it's still not working. I've checked that the formatting of the phone number has all non-numeric characters removed.

Yes! We have this problem all the time. Sometimes the feature works and then it stops and getting it working again is near impossible. We have tried resetting settings on iPhone, deleting the app, turning off the feature, rebooting the phone, reinstalling... and then after a zillion tries, sometimes it starts working again. All of our numbers are correct with the proper international code as well. There's no reason for this that we can see.

caller id


Download Zip https://pimlm.com/2yS8nW



If this behavior continues after trying those steps, I would recommend connecting with HubSpot Technical Support, as Support is included in your subscription. Support will be able to provide real-time assistance for this matter, where you are able to share screenshots or screen recordings, and further information about this.

The part above about going to the contacts area and refreshing fixed everything for us! We don't use the contacts section hardly ever and so when I clicked on it, it loaded the contacts with a progress bar moving across the screen. Once that concluded, I quit and reloaded the app and everything was working perfectly!

If you've enabled the Caller ID following the steps in this Knowledge base article and you've also made sure that your contacts' phone number values include the + country code, the next troubleshooting step I'd recommend is to uninstall the app, restart the device, and reinstall the app.

Thanks for this. I have followed all the steps for setup, and at this point Caller ID seems to work sometimes, but not all the time, and with no predictable pattern. Does anyone else out there have this issue?

Non-standard: This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

The caller accessor property of Function instances returns the function that invoked this function. For strict, arrow, async, and generator functions, accessing the caller property throws a TypeError.

If the function f was invoked by the top-level code, the value of f.caller is null; otherwise it's the function that called f. If the function that called f is a strict mode function, the value of f.caller is also null.

Note that the only behavior specified by the ECMAScript specification is that Function.prototype has an initial caller accessor that unconditionally throws a TypeError for any get or set request (known as a "poison pill accessor"), and that implementations are not allowed to change this semantic for any function except non-strict plain functions, in which case it must not have the value of a strict mode function. The actual behavior of the caller property, if it's anything other than throwing an error, is implementation-defined. For example, Chrome defines it as an own data property, while Firefox and Safari extend the initial poison-pill Function.prototype.caller accessor to specially handle this values that are non-strict functions.

Note that the only behavior specified by the ECMAScript specification is that Function.prototype has an initial caller accessor that unconditionally throws a TypeError for any get or set request (known as a \"poison pill accessor\"), and that implementations are not allowed to change this semantic for any function except non-strict plain functions, in which case it must not have the value of a strict mode function. The actual behavior of the caller property, if it's anything other than throwing an error, is implementation-defined. For example, Chrome defines it as an own data property, while Firefox and Safari extend the initial poison-pill Function.prototype.caller accessor to specially handle this values that are non-strict functions.

If they are, you could do what I did and contract with a second provider specifically for the purpose of sending calls to the company cell phones. This account is set up with no Caller ID (which is why I got it) and the provider has no restrictions on what Caller ID I send. I route all of the calls for our important cell phone numbers out to that carrier so that I can control what information get transmitted to the people in the company.

Yes we recommend setting a caller ID on the trunk but with it set to allow any cid it will use the CID that is passed not the one in the trunk. Sounds like to me your carrier is not sending what you send.

In our org the front line managers create new accounts for new employees and submit grant permissions requests for them on myesri. It's great and work pretty well. One thing that I think used to work but no longer does for us is the "Authorized Caller" grant. The managers don't add this grant, I don't think they try - so I always go in there and manually add that permission to the grant list and hit "submit"

I know the workaround is to go to the authorized caller area and add them there, but it sure would be nifty if that little permission would work or quit teasing me and go away , preferably the former.

For admins who may have also encountered this, too, the bug is that if you fill out the "Take authorized caller actions" section on the form you see from My Organizations > Users > Manage Requests when you grant a user permissions, the authorized callers settings don't "take". You have to add them again using another method (My Organizations > Users > Manage Authorized Callers > Add Caller, or My Organizations > Users > Edit Permissions) as a workaround.

I don't think we need a movie at this point (mostly because I don't want you to have to post private information), but could you try again, but this time with the developer tools of your browser open? View its Network tab, and keep an eye out for any text that comes up in red. A screenshot of that with any errors would be helpful.

Interesting. In the post event, it returns what is supposed to be an alphabetized list of all callers - except for "kyle" who I just added. Perhaps also related are the two null records right about where Kyle would fall.

I didn't see a link to your movie anywhere, but the "null" users you point to in the image above are legitimate. You've invited several folks to your organization, and since they haven't accepted their tokens yet, My Esri has no usernames for them yet. So they are correctly shown as "null" in your screenshot.

Hi all,
is there a way to identify a frequent caller?
eg. someone who is calling for the fourth times in the last 24 hours? or, from a caller number, determine how many times he calls in the last 24 hours?

Method 1
If you know the ANI/CLI of a caller (their phone number) and you want to know how many times he called in last 24 hours (or in a given interval), you can use an Analytics Query for Conversation Details.
This is what I described in this post: -of-interations-per-ani/10028

You can also use this same Analytics Query for Conversation Aggregates to retrieve the number of times each ANI/CLI called in the interval. But you would also get people who have called one time only. So you would need to parse the response and check data/people who have a nOffered or nConnected metric greater than 2, 3 4, ...
The aggregate query will group data by ani.

I am on the New York upgrade where it has the new business rule that if the 'Caller' responds to an Incident that is in the 'On Hold - Awaiting Caller' state it sets the state back to 'In Progress'.

This will work if the caller sends the response via our companies email. Users also have the ability to email from the alternate email (gmail, yahoo, icloud) and it is recognizing the user when the submit the Incident (does not post as Guest). But once they respond via alternate email it automatically post their response as 'Guest' in the activity field. This does not match with the business rule, therefore it doesn't think the caller has responded so it will never change back to 'In Progress'.

59fb9ae87f
Reply all
Reply to author
Forward
0 new messages