A valid signature still needs a trust decision
An Oprindo sample had a matching asset hash and a valid signature, alongside an untrusted credential result. The useful story is in those separate answers.
Integrations7 min read
A connection is someone’s ongoing responsibility
A source-read/report-write example shows why business purposes, OAuth scope and revocation boundaries need separate records.
Connected is a relationship with a future
The weekly report can keep showing correct calculations long after its source connection stops supplying current data. Perhaps the person who authorised the spreadsheet has changed role; perhaps the next refresh now fails. The visible totals alone cannot tell a reader. Someone needs to know which account, application and grant supplied the access, who owns it now and when the data last moved. Connected is a useful label only while that continuing relationship has someone able to maintain it.
Take a proposed timesheet-to-summary job. It reads source spreadsheet T1 and writes report R1. An integration register might sensibly contain two purpose rows, one for source reading and one for report writing. Those rows are useful business descriptions. They do not prove that the provider has issued two independently scoped or independently revocable grants. Distinguishing the intended jobs from the technical permission boundary is the first piece of work an honest connection register needs to do.
OAuth describes authorisation for an application to access protected resources. An access token is used for those requests; a refresh token, when issued, can obtain another access token under the grant.[1] This is different from proving who is signed into the report's own interface. Mixing those questions can lead to an odd arrangement in which a colleague can log into the application but nobody knows which account's authority lets its scheduled process read the source. The register should identify both relationships clearly.
The downloadable register is a proposed design, with unknown account and technical-grant details deliberately left blank. No live grant was created or revoked. Current Google documentation supplies the concrete comparison: the access needed to read T1 and the access available to change R1. Putting those facts beside the intended purpose lets the reviewer ask whether the connection actually fits. The blank fields are work still to do, not permission boundaries the register acquires merely by naming them.
Narrowing the files and narrowing the actions are different choices
Google's Sheets scope documentation describes spreadsheets.readonly as read access to the user's spreadsheets, while drive.file covers the specific Drive files used with the app and includes editing, creation and deletion capabilities.[2] The two choices narrow different dimensions: one limits actions across a broader file set; the other limits files while allowing more actions within them. Comparing both dimensions against T1 and R1 is necessary to describe the actual exposure.
T1 illustrates the difference between a provider limit and an application rule. A read-only scope can prevent mutation through that scope while still allowing reads beyond this timesheet. Restricting application requests to T1 helps, but does not make the provider grant T1-only. R1 has the converse problem: a per-file scope can match the resource boundary while permitting more than a write to the intended summary range. Calling either connection only what the job needs would hide the dimension in which it remains broader.
The Sheets documentation also makes clear that scopes cannot be confined to one individual sheet within a spreadsheet.[2] A design that treats a tab named Report as its security boundary would therefore be overstating what that scope enforces. Resource sharing, protected ranges, application argument checks and account authority may add relevant restrictions, but they are distinct mechanisms. A register can name which layer supplies each limit instead of pretending that a single consent screen expresses the whole business policy.
There is no universal winner. A separate output file may be worth maintaining because it creates a clearer resource boundary; an occasional manual export may avoid a persistent grant entirely. Conversely, several coordinated jobs can legitimately share a connection when their ownership and retirement requirements align. Splitting every purpose into another application can create consent and operational overhead without automatically creating the isolation people expect. Inspect provider boundaries before multiplying registrations to solve a problem that may require a different resource arrangement.
Follow the grant when the token changes
The register should retain the purpose, provider, application or project identity, authorising account, granted scopes, affected resources, operational owner and a reference to credential storage. It should not contain the token itself. For T1 and R1, keep separate observations of the last successful source read and destination write. A current source read with an old report points towards the write stage; two old observations point towards retrieval or scheduling. The timestamps should identify successful capabilities, not merely the latest attempt. That lets the new owner start at the failing hand-off instead of renewing both connections and rerunning a job whose partial progress is still unexplained.
An expired access token need not end the relationship if a valid refresh mechanism can obtain another under the grant. A rejected refresh is different: repeating the same request will not produce renewed consent. The report should show its freshness, and the connection owner needs the account that can authorise continuation. Otherwise the reader is left studying unchanged totals for clues about the integration’s health. That is a poor responsibility to give someone who opened the report to understand the business.
The account authorising access may differ from the person responsible for the business process. When that operational responsibility changes, establish which account model, resource owner and renewal procedure the organisation permits. The procedure is provider-specific and should be available to the new owner without requiring another person's password. Otherwise an ordinary handover can leave staff unable to maintain the report, or encourage an unnecessary expansion of access simply to restore it.
Google’s current web-server guidance describes combined authorisation across scopes and project-wide revocation consequences for the associated user’s grants, including clients within the project.[3] Two purpose rows, or even two client names, therefore do not establish two independently disposable connections. Follow the actual grouping before retiring T1. If that action would also disable another report, the owner needs to know while there is still time to plan the change rather than discover the relationship from two failing schedules.
Two purposes do not prove two permission boundaries
Proposed Google Sheets integration register, compared with current provider documentation. No live grant or revocation tests were performed.
Scroll sideways to see all columns.
| Purpose / candidate | Resource breadth | Action breadth | What the register must say |
|---|---|---|---|
Read T1 / spreadsheets.readonly | User spreadsheets | Read | T1 allow-list is an application limit |
Write R1 / drive.file | Specific app-used files | Read/edit/create/delete | Broader actions than writing summary cells |
| Separate purpose rows | Not evidence of isolation | Grant grouping unverified | Identify actual account/project/grants |
| Retire source reader | Related scopes may be affected | Provider revocation semantics | Check dependent jobs and verify end |
End the capability as carefully as the schedule
Deleting a scheduled job stops that particular programme from using its token. It does not by itself demonstrate that the issued capability has ceased to exist. RFC 7009 defines a token-revocation mechanism and notes that related tokens or the underlying grant may be affected.[4] For an actual provider, consult its supported procedure and scope of invalidation. A successful HTTP response and complete loss of access are related observations, but the operation may have propagation behaviour worth accounting for.
The proposed retirement record first names the purposes affected, stops automated use, records authorised revocation and leaves room for verification. A provider-appropriate check might confirm that renewal or a harmless authorised read is rejected as expected, without repeatedly attempting mutations. Google notes that full revocation can take time.[3] Requested, pending verification and verified ended are consequently different states. A rejected revocation request needs a failure reason and an owner; it is different from an accepted request still waiting for its effects to propagate.
Credential disposal and report history remain separate tasks. Remove retained credential material according to the organisation's process, and label the last report as static or no longer refreshed. Revocation does not retract copies already written into R1 or erase a previously exported file. If the reason for retirement involves data retention, those copies need their own decision. Keeping access lifecycle and data lifecycle distinct prevents a connection removal screen from promising an erasure it has not carried out.
A small organisation can keep these relationships in the two-purpose register without building another administration system. The important blanks concern actual capability, the authorising account, responsibility for stale output and other jobs sharing the grant. Separate read and write freshness helps the next owner locate the failing stage. When the report is finally retired, that same record can explain both that its schedule stopped and that its access ended. Those are different parts of finishing the job.
Retirement is a lifecycle decision
Proposed states for ending the T1/R1 connection; no live revocation was performed.
Follow the labelled arrows. On a narrow screen, scroll sideways if needed.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotReferences & further reading
Primary sources behind this article. Living documentation may change.
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A few more things
worth a read.
Back to the reading room 
Should this old instruction still run?
Repairing a consumer makes replay possible. Current state, dependencies and recovery admission decide whether it is still appropriate.
The backfill arrived after the live update
Historical work needs a population boundary, revision policy and crash-safe checkpoint strategy before its final page can mean done.