On this page
A team connects an external application and sees a successful setup message. Colleagues assume the business records are now synchronized. Later, they discover that the connection saved its configuration but did not provide the data movement they expected.
An integration authorization review connects the business purpose to the access granted and the behavior the provider actually supports. It establishes which systems and records are involved, who owns the connection, and what evidence will show that the intended work occurred. Review those questions before relying on the connection in an operating process.
Define the purpose and the expected data path
Describe one concrete outcome. “Bring supported delivery activity into the owning workflow for review” is more useful than “connect the supplier system.” Name the source, destination, record type, and person who will use the result.
Establish the direction of movement. Reading external records, creating records in another service, and changing existing data are different capabilities. A connection can support one without supporting the others. Check the capabilities shown for the provider and the current configuration before describing the workflow to colleagues.
Record what remains manual. If an adapter only supports configuration, the team needs a separate process for the intended data transfer. A saved connection should not become evidence that the transfer happened.
Define a limited verification task and a clear expected result. Use permitted test information that can be identified and reconciled without introducing unnecessary business changes.
Review the access requested by the provider
Inspect the actual permissions, accounts, and resources involved in authorization. Match them to the defined purpose. A service may request access broader than the team expected, or offer account choices with very different business scope.
NIST's least privilege definition describes limiting system privileges to what assigned work requires. Apply that principle to the permissions being granted, then review the provider's own explanations of what those permissions allow.
| Authorization question | Decision to record |
|---|---|
| Which account is connected? | Intended business account and responsible owner |
| Which resources are accessible? | Permitted workspace, organization, or record scope |
| Can the connection read or write? | Capabilities required for the business purpose |
| What remains outside the purpose? | Scope to exclude or review before proceeding |
| Who can authorize this setup? | Person with the relevant organizational authority |
When a permission cannot be narrowed, bring the tradeoff to the appropriate owner. Record the decision and its conditions. Do not assume that someone who can configure a connection is also authorized to expose every accessible resource.
Keep credentials and responsibility in the owning system
Use the approved authorization interface and secret storage. Keep tokens, passwords, and recovery information out of ordinary notes, screenshots, chat messages, and exported setup reports. A review record should reference the protected configuration rather than reproduce it.
Name an operational owner and an authorized person who can handle credential or permission changes. They may be different colleagues. Establish how each will receive attention items and who covers the connection when the usual owner is unavailable.
Identify dependencies such as an external account, provider plan, authorized administrator, or required verification step. Record those that affect readiness without treating them as evidence of support for additional features.
Figena's Integrations workspace presents supported connections, capability and readiness information, health, and attention items. Data movement depends on the provider adapter; configuration-only connections do not establish synchronization.
Check mapping and separation before using the result
Where an adapter provides external activity, review how it maps into the owning business workflow. Confirm the intended organization, account, category, and record identity using the options actually available.
Similar labels need investigation. An external account called “Main” may not refer to the same entity as a destination account with that name. Confirm the underlying business meaning before accepting the mapping.
Keep organizational boundaries explicit. A valid credential can still belong to the wrong business account. The person verifying the connection should check both the authorization context and the destination context.
Define how duplicate or uncertain records will be handled through the supported process. If an attempted transfer has an unclear result, inspect the destination and provider activity before repeating it. A retry should be based on evidence of what already happened.
Verify the actual result and its freshness
Run the approved limited check where the adapter supports it. Compare the source record with the destination result, including identity, expected fields, relevant times, and intended scope. Record any transformation that changes how a value should be interpreted.
Distinguish setup, provider verification, connection health, and completed business activity. These signals answer different questions. A healthy connection may still have a mapping issue or no recent activity to supply.
| Observed signal | What it establishes | What to check next |
|---|---|---|
| Configuration saved | Setup information was accepted | Supported capability and verification state |
| Provider verification passed | The stated provider check succeeded | Its scope and the intended business result |
| Connection health available | The current health assessment | Assessment time and outstanding attention items |
| Destination record found | A particular result exists | Correct source, mapping, fields, and freshness |
Use actual source and result timestamps when deciding whether information is current enough for the task. A page load time does not establish the time the external information was produced or transferred.
Review changes and disconnect deliberately
Revisit the review when the business purpose, provider, owner, required permissions, or destination changes. Inspect the current configuration and behavior instead of carrying an old acceptance decision forward automatically.
Give each credential, mapping, or health issue a next action and owner. If the integration cannot perform the intended task, state what is blocked and use an approved alternative process until the issue is resolved. Do not present the missing activity as an empty but successfully synchronized result.
When the connection is no longer needed, use the supported disconnection and provider revocation processes. Check the result in the service that controls the authorization. Disconnecting a local configuration may not revoke a provider-side grant or remove information already transferred.
Retain necessary business records under the organization's policies. Treat data retention and authorization removal as separate decisions, with their own responsible owners and verification.
A hypothetical connection review
Consider a hypothetical operations team connecting a provider to obtain activity for a specific business account. The setup owner first documents the account, intended record type, data direction, permitted resources, and expected destination.
The capability review shows that the selected connection currently supports configuration but not the intended activity transfer. The team records that limitation and assigns the approved manual process to an owner. It does not announce that records are synchronized.
If the team later selects a provider adapter that supports the required transfer, the owner reviews authorization and mappings again. A permitted sample confirms one result in the intended workflow, with source identity and timestamps checked. Wider use follows that review rather than the earlier setup message.
Use a concise acceptance record: purpose, account scope, permissions, supported capability, configuration reference, mapping decisions, verification result, operational owner, and next review trigger. The record should explain why the connection is appropriate and what the team has actually observed.
