An add-on should have read access rather than write access when its task only requires viewing, searching, summarizing, or analyzing information already available through the connection. Write access is unnecessary if the add-on must not create, edit, send, or delete anything in the connected system; displaying a draft inside the add-on is different from saving that draft to the source.
App permissions do not by themselves grant an app new access. A narrow add-on permission list is therefore not a complete review: the underlying connection and the information it can already reach also matter.
Start with the intended workflow
The access decision should follow the minimum operations required for the task:
| Intended operation | Appropriate access |
|---|---|
| View, search, or summarize existing information | Read access |
| Analyze existing content and return a response without changing the source | Read access |
| Prepare a draft without saving it to the connected system | Read access |
| Create, edit, send, or delete connected content | Write access for those actions |
| Read content in one stage and update it later | Review the stages separately |
A useful test is whether the add-on can complete its defined task without changing the connected environment. If it can, granting write access would expand the permission boundary beyond the immediate requirement.
How to check the integration
- Define the task in one sentence. The intended result should be specific enough to distinguish reading information from changing it.
- List every expected action. This includes less obvious write actions such as sending a message, saving a document, updating a record, or deleting an item.
- Match each permission to an action. Any permission without a corresponding task requirement should be removed or sent for separate review.
- Inspect the underlying connection. Because app permissions do not grant new access, reviewers must check what the connection already makes available rather than examining the add-on in isolation.
- Use available administrative controls. In the connector environment covered by the documentation below, administrators can review and validate each connector’s access permissions from the connection details pane in the admin center.
- Test with representative, non-sensitive material. The test should confirm both that the add-on can perform the read-only task and that it does not attempt an unapproved write action.
Read-only access removes the need for direct modification, but it does not remove the need to review data reach, permission scope, or internal handling requirements.
What the team must still confirm
Before approval, the team must verify:
- Which data the underlying connection can reach.
- Whether the requested read scope covers the intended task without including unnecessary material.
- Whether any later step is expected to save, send, update, or delete content.
- The current permission descriptions and applicable data-handling, retention, security, and internal compliance requirements.
- Who approves the connection and how the permission scope will be reviewed again if the workflow changes.
The cited documentation does not replace these project-specific checks. If the team cannot confirm that read-only access is sufficient—or cannot identify the write actions a workflow requires—the integration should remain pending review rather than receiving broader permissions by default.
A practical decision rule
Choose read access when all three conditions hold:
- The task can be completed using information already available through the connection.
- The add-on does not need to create, change, send, or delete anything in the connected system.
- The underlying connection’s data reach and the add-on’s requested permissions have both been reviewed.
If any condition is unclear, the team should resolve it before granting write access.