Authorising a piece of software, seeing action by action what the connection genuinely permits, and cutting it whenever you want.
A connection authorised with your own account at your provider, and a screen stating, action by action, what that connection permits: read, create, modify, cancel. All four lines are shown even when three are refused — that is the point.
You will also know which of the two systems has authority. When your software is the system of record, the receptionist adapts to it; when the workspace is, it decides and your software follows.
Allow ten minutes, provided you have at hand the account allowed to authorise a connection at your provider.
No password for your software reaches us: authorisation happens at the provider, and the token is encrypted on our side.
The entry states the provider, the edition and the account's region. Those three change what is permitted: they are not an administrative detail.
You are sent to the provider, you sign in there, and you come back. Your account grants the access, and you can withdraw it from their side as well as ours.
Read, create, modify, cancel: each line says whether the action is qualified or still to be qualified. An action still to be qualified will not be attempted — the receptionist collects a request instead.
For appointments, only one of the two systems decides. That choice avoids the situation where each overwrites the other in turn.
The screen shows the last test evidence actually executed, not a promise. If the connection drops, this is where you learn it before your customers do.
«Connected» means nothing to an owner. What matters is what the connection can do: read availability, create an appointment, change it, cancel it. Two products of the same name, in two different editions, do not permit the same actions — and the difference shows up during a call.
So the four lines are displayed separately, including the refused ones. An action that is not qualified is not attempted: the receptionist takes a request, the customer knows a confirmation is coming, and you are not left repairing a promise the system could not keep.
For appointments, one of the two systems decides. That choice is not a matter of taste: without it, a change made here and a change made there overwrite each other in turn, and the last write wins by accident of timing.
Authorisation happens at your provider, with your account. We do not receive your password; the access token is encrypted on our side and can be withdrawn from either end — from the Connections screen, or from your account at the provider. Each withdrawal leaves a timestamped trace in your audit trail.
Describe what you want linked rather than the product name: reading availability, creating a customer record, filing a request. That is what the «my software» page is for, and many needs are covered by the tools already in the workspace.
Authorisation needs an account allowed to grant application access at the provider. Have that person do it: an authorisation attempted from an ordinary account fails, and the error comes from the provider, not from us.
The screen shows the last test proof actually run, with its time. In the meantime the receptionist falls back on taking a request rather than announcing a confirmation she cannot verify.
Revoke the old connection before authorising the new one, and set the master system again. Appointments already created stay where they are: revoking cuts access, it erases nothing at your former provider.
Each site carries its own connection. A single account wired to both mixes availability up and offers times from one site to customers of the other.
The account used probably lacks the right to grant application access. Try again with an administrator account for your organisation at that provider.
That is a normal, displayed state: some actions are not qualified at that provider. The receptionist then collects a request, and you confirm inside your software.
The system of record is unset, or it was changed midway. Fix it, then correct once by hand: the rest holds on its own afterwards.
Revoke from the Connections screen, or from your account at the provider. Both work, and the withdrawal leaves a timestamped trace in your record.
What owners ask about connections.
No. The receptionist answers, qualifies and summarises with no connection at all. Software gets linked when it brings something specific: real availability, an existing customer record, a follow-up already in place.
No. Authorisation happens at your provider, on their sign-in screen. We hold an encrypted access token, which you can withdraw from their side as well as from ours.
That it has not been verified for this edition of the software and will therefore not be attempted. The receptionist takes a request instead, and the screen says so rather than letting you assume everything goes through.
That is why the four lines stay on screen even when three of them are refused.
The screen shows the last test proof run, with its time, rather than a decorative green dot. A dropped connection is visible there before your customers notice it.
Yes, from either side, and it takes effect immediately. The withdrawal leaves a timestamped trace in your audit trail, so you can see what was done before the cut.
The master system you set. When it is not set, fix that first, then correct the record once by hand: after that it holds on its own.
Every task has its own.
The pages covering each piece of software.
