Compatibility cannot be confirmed from the available documentation. Connected-app permission settings determine when approval is requested before information is read or an action is taken, while overly broad connector access can lead to oversharing sensitive content. Neither point establishes that the add-on integrates with the team’s existing sign-in, identity, or administrative controls.
An approval prompt demonstrates a permission check, but it does not by itself prove that the existing authentication system is supported.
How to check the fit
| Control area | What the documentation establishes | What the team must check |
|---|---|---|
| Authentication | No compatibility details are provided. | Whether the add-on supports the existing sign-in method and preserves the correct user, group, and role assignments. |
| Approval timing | Connected-app permissions determine when approval is requested before reading information or taking an action. | Whether approval occurs at every point required by the team’s access policy. |
| Sharing scope | Broad settings, including access for Everyone, can lead to oversharing. | Whether each test user can reach only the resources permitted by the team’s policy. |
| Administrative control | The documentation focuses on permission and connector access settings. | Who can grant, change, or revoke those permissions, and whether existing administrator boundaries still apply. |
| Access changes | No process for role changes or removal is described. | What happens to access when a user leaves a group, changes roles, or is offboarded. |
A practical check should follow four steps:
- Record the current controls. Note the approved sign-in route, user and role structure, actions requiring approval, and prohibited sharing scope.
- Compare each control with the documentation. Treat an unanswered authentication or administration question as unresolved rather than assuming compatibility.
- Use a controlled test where permitted. Test reading and acting separately with non-sensitive sample data. Do not use sensitive content until the sharing scope is confirmed.
- Keep written evidence for each answer. Permission screens can demonstrate current behavior, but they do not replace documentation about authentication support or administrative control.
What still requires confirmation
Before the add-on is considered compatible, the team needs documented answers to these questions:
- Does the existing authentication method work with the add-on?
- Do users, groups, and roles map to the same access assignments?
- Can broad access such as Everyone be excluded?
- Are approvals triggered before each policy-relevant read or action?
- Which administrators can grant, modify, or revoke access?
- How is access updated when responsibilities or employment status change?
Any unresolved item should remain a rollout blocker rather than be recorded as a successful integration check.