Caller identity
Access modes decide who may dial. This page is about the question that follows: once someone is connected, who is your agent talking to — and what is that person allowed to do?
It matters because an agent on a phone line has the same tools as an agent anywhere else. It can read tables, search documents, call APIs. Identity is what decides which of those a given caller gets.
Three possible identities
When a call arrives, qRaptor resolves the caller to one of three identities, in this order.
| # | Identity | When | What the agent gets |
|---|---|---|---|
| 1 | Known caller | The caller’s phone number matches a user registered in this project | That user’s real identity and their roles |
| 2 | Service account | No match, and the number has a service account | The number’s own identity, with the permissions you gave it |
| 3 | System fallback | No match and no service account | A generic telephony identity with no roles |
The first match wins. Everything the agent does for the rest of the call happens as that identity — governance rules, row filters and column masks all apply to it exactly as they would to a signed-in user.
1. Known callers
If the caller’s number matches a user in the project — the same users you manage under Security → Users — the agent treats them as that person, with their roles.
This is the interesting case. A patient ringing a clinic line gets their records, not everyone’s, without logging in or proving anything beyond the number they called from.
Caller ID is the only proof. A matched caller is authenticated by their phone number and nothing else, and caller ID can be spoofed. Don’t put anything behind phone identity that you wouldn’t put behind a phone call to a human receptionist. For genuinely sensitive actions, have the agent verify something only the real person would know.
2. The service account
Unknown callers are the normal case on a public line, and they need some identity — an agent with no identity can’t use a governed tool at all.
That’s what the service account is. It’s a real user in the project, created for one specific phone number, and it’s what every unrecognised caller on that number becomes. Give it the narrow set of permissions an anonymous caller should have, and that’s the ceiling for anyone who dials in off the street.
Because it’s per-number, two numbers pointing at the same agent can grant different access. A public sales line and an internal staff line can share one agent and still see different data.
3. System fallback
If there’s no service account, the caller becomes a generic telephony identity with no roles. The agent will answer, but any governed tool call is likely to come back empty or denied.
qRaptor treats this as a gap to close: on the first call that falls through, it provisions a service account for the number in the background, so subsequent calls land on case 2. You don’t need to do anything, but you also shouldn’t rely on it — an account created this way arrives with the same empty role as one you create by hand, so it still needs permissions before it’s useful.
Create a service account
A newly provisioned number has no service account. Its card shows Not set up with a Create button under Service Account, and the detail page offers Create Service Account. Click either one — it takes a second.
If you don’t, qRaptor creates one for you on the first call that needs it: a caller who resolves to the system fallback triggers a background provision, so the second such call already has a proper account. That’s a safety net, not a plan — the account it creates has no roles, so create it deliberately and assign roles rather than waiting to find out.
Once it exists, the detail page shows Status: Provisioned, and the number’s card shows Provisioned in place of the button.
The account appears in Security → Users with a Telephony badge. It’s a system account: you can edit it — which is how you assign roles — but you can’t disable, password-reset or delete it.
Creating the account is only half the job. It’s given a role called telephony-caller, and that role is created empty — it grants nothing. Until you attach permissions to it, unknown callers still can’t reach governed data.
Assigning those permissions is the whole point of the account existing. Decide what an anonymous caller on this number should be able to see, then grant exactly that and no more.
Memory across calls
Alongside identity, qRaptor passes the caller’s phone number to the agent as an end-user key. Anything the agent stores in memory is filed against that caller, so a repeat caller can be recognised on their next call — even if they’re an unknown caller with no user record.
That’s what makes “welcome back, shall I use the same address as last time?” possible on a public line.
Common issues
- A known caller is treated as anonymous — the stored number doesn’t match the number they dialled from. Matching compares the last ten digits, so notation isn’t the issue; a different handset is.
- The agent can’t read any data on a call — either the caller is resolving to the system fallback, or the service account’s
telephony-callerrole has no permissions on it. Check the number has an account, then check what that role actually grants. - Two numbers should have different access but behave the same — they’re likely sharing one identity because one has no service account. Each number needs its own.
- You can’t delete a telephony service account — correct, and deliberate. Release the number and the account stops being used.