Review Link Approvals
Use the Link approvals tab to review requests to link a new sign-in identity to an existing account. A request appears when someone signs in through a provider whose identity is new to Qualytics but whose email matches an existing account, and the provider requires administrator approval for linking.
The tab shows a badge with the number of pending requests. Each request is one row with the requester, the provider, the trust evidence recorded at sign-in, and when it was made, so you can compare requests at a glance and open the details only when something looks off.
Permissions
Only users with the Admin role can review link approvals. See the Permissions page for details.
What Each Request Shows
| Column | Description |
|---|---|
| Requester | The name and email of the existing account the identity wants to link to, next to an avatar with the person's initials. When the provider presented no name, the email stands in; when it presented neither, the row shows the account number. Hover the information icon for the Requester details tooltip: Name, Email, Provider Type, and Account ID, the identifier the identity provider sent for the person. |
| Provider | The sign-in provider the request came through, shown as a badge with the provider's name next to the icon of its type. Hover the information icon for the provider's Name and Type (OpenID Connect, SAML 2.0, or Email & Password). |
| Trust evidence | Three colored dots, one per signal, that summarize what supports the request. Hover the column for the Trust evidence tooltip, which names each signal with its answer and adds a note on how to read it for that provider type. See Reading the Trust Evidence below. |
| Requested | How long ago the request was made. Hover for the exact date and time in your local time zone. |
| Approve and Reject | The two decision buttons at the right end of the row. They stay visible while you scroll a wide list sideways. |
Copy actions
Right-click a row to open a menu with Copy name, Copy email, and Copy account ID. The name and email entries appear only when the provider presented those values.
Reading the Trust Evidence
Each dot answers one question about the identity the provider asserted. The color is the answer:
| Dot | Answer | Meaning |
|---|---|---|
| Yes | The provider asserted the signal. | |
| No | The provider asserted the opposite. | |
| Not asserted or Not recorded | Not asserted means the provider did not report the signal at all. Not recorded means the request predates the current evidence record or was created outside the sign-in flow, so no evidence exists for it. |
| Signal | What it tells you |
|---|---|
| Email verified | Whether the provider reported the person's email address as verified. OpenID Connect providers are not required to report this, and many do not, which shows as Not asserted. SAML 2.0 providers always show Yes. |
| Domain match | Whether the email domain is in the provider's Allowed Email Domains. It is also Yes when the list is empty, because every domain is then allowed. |
| Signed assertion | Whether the identity arrived in a signed assertion. Yes for every SAML 2.0 request. No for every OpenID Connect request, because those providers deliver the identity in an ID token instead, which Qualytics verifies before reading any claim. A red dot here is expected for OpenID Connect and is not a reason to reject on its own. |
The evidence is recorded once, when the request is created, and describes that sign-in attempt. For SAML 2.0 providers the three answers are the same for every sign-in, so they confirm the provider type rather than measure the individual request. Weigh the evidence together with what you know about the person and the provider: a request from a provider you trust to be authoritative for its users' email addresses needs less scrutiny than one from a provider that lets people pick their own address.
What the Requester Experiences
- While pending: sign-in attempts through that provider are refused with a message that the account link is pending administrator approval and to try again after it is approved.
- After approval: no notification is sent; the person simply signs in again and it succeeds.
- After rejection: sign-in attempts through that provider are refused with a message that the request was not approved and to contact an administrator. Any session that was already open through that identity ends.
Info
Whether a link needs approval at all is controlled per provider by the Cross-provider account linking and Require administrator approval settings. See How It Works. Because this tab lists only pending requests, reversing a rejection is done through the API.
Steps
Step 1: From any page of the application, open Settings in the left sidebar. The Settings page opens with its tabs across the top.
Step 2: Click the Access tab.
Step 3: Click the Link approvals tab. The badge on the tab shows how many requests are waiting. The list opens under the heading Pending identity-link requests; when nothing is waiting, it reads No identity-link requests pending approval instead.
Step 4: Locate the request you want to review. Requests are listed in pages; use the pagination controls above or below the list to move between pages or change how many rows each page shows.
Step 5: Review the request. Check that the Requester is who you expect, that the Provider is one that should be able to vouch for that person, and what the Trust evidence dots say. Hover the information icons and the evidence column for the details.
Step 6: Approve or reject the request:
Click Approve at the right end of the row. The Approve Identity Link dialog opens with the requester's name and the provider at the top, and asks whether you are sure you want to approve this identity link. The dialog reminds you that the person can sign in through this provider on their next attempt and that nobody is notified, so tell them to try again.
Click Approve to confirm. If you want to cancel this action instead, click Cancel or the X in the top right corner of the dialog; the request stays pending.
Click Reject at the right end of the row. The Reject Identity Link dialog opens with the requester's name and the provider at the top, and asks whether you are sure you want to reject this identity link. A warning explains that the action cannot be undone from this screen: the person will not be able to request this link again, any session already opened through it ends, and nobody is notified.
Click Reject to confirm. If you want to cancel this action instead, click Cancel or the X in the top right corner of the dialog; the request stays pending.
Step 7: A success message appears, the dialog closes, and the request leaves the list. The badge on the tab drops by one. If it was the last request on the current page, the list moves back to the previous page so you are never left looking at an empty page while requests remain. Approvals and rejections are recorded in the sign-in log.