Every Connector Is a Push and a Cap
The connectors in this product share one shape: they push rather than pull, they are safe to run twice, they stop at two hundred records a run, and the button and the nightly job are the same code. Each of those four is a decision worth understanding before relying on one.
A connector that can be run twice without consequence is a connector somebody will actually press the button on.
Several integrations here move a workspace's records into somebody else's tool: deadlines into a calendar, registers into a spreadsheet, customers and suppliers into a database or a table. They are built to a common shape, and the shape is more interesting than any individual connector.
They push, and only push
Each one takes records from the workspace and writes them into the destination. None of them reads back. That is a deliberate and quite restrictive choice, and it removes the hardest problem in integration work — deciding which side wins when both have changed.
A two-way connector has to answer that question on every field of every record, and the answer is always a policy somebody has to understand. A one-way push has a single rule: this system is the source, the destination is a copy. Anybody editing the copy is editing something that will be overwritten, and that is easy to explain and hard to get wrong.
The destination is a view, not a workspace
The practical consequence is worth being blunt about. A spreadsheet or a database populated by a connector is a place to read, chart and share from — not a place to work in. An edit made there is lost on the next synchronisation, silently, and the person who made it has no way to tell. Where people genuinely need to edit in the other tool, the honest answer is a two-way integration with a stated conflict policy rather than a push somebody hopes nobody writes to.
They are safe to run twice
Every one of them is idempotent through a stable key, and each one names what its key is: a calendar event keyed so that a moved date updates the same event, a table record merged on its primary field, a page matched on its title.
That property is what makes a "sync now" button reasonable to offer. Without it, pressing it twice produces two calendars' worth of events, and the feature becomes something people are afraid of. With it, pressing it is free, and the natural response to "is this up to date?" is to press it rather than to investigate.
It is also what makes the scheduled run safe. A job that overlaps its predecessor, or runs twice because something was retried, does no damage — which means the schedule can be simple rather than defensive.
A button you can press twice is a button people press once, and trust.
They stop at two hundred
Each run is capped. That is the property most likely to surprise somebody with a large workspace, and it is the right trade for three reasons worth spelling out.
-
The destination has its own limits
Every one of these services rate-limits, and a connector that ignored that would produce a partial synchronisation with a failure at an arbitrary point rather than a complete one with a known boundary.
-
An unbounded push is an unbounded run
A synchronisation that scales with the size of a workspace is one that eventually takes long enough to overlap the next one, and nobody notices until it does.
-
A known cap is diagnosable
Two hundred records synchronised out of a larger set is an explicable outcome. A synchronisation that stopped somewhere unpredictable because a remote service objected is not.
What that means practically is that these connectors are built for the working set rather than the archive. A calendar of upcoming deadlines, a table of active customers, a spreadsheet of current registers — all fit comfortably. A complete historical export is a different job and wants a different tool.
The horizon, on the one that has dates
The calendar connector adds a second bound that the others do not need: it looks a hundred and eighty days ahead and never behind. Three kinds of deadline are pushed — purchase order deliveries, approvals coming due, and sourcing response deadlines — each switchable on its own.
Never looking backwards is the more considered half. A calendar is a forward-looking instrument, and pushing historical deadlines into it produces a calendar nobody can read for the thing it exists for. Six months ahead is far enough to plan around and short enough that the calendar stays about the near future.
The button and the job are the same code
Every one of these is documented as safe to run from a manual button or from the schedule, and both routes run the same implementation. That is the fourth shared property, and it is the one that prevents the most common integration complaint: a manual synchronisation that behaves differently from the automatic one, so "I pressed the button and it worked" and "it has not updated overnight" are two separate investigations.
The permission granted is the narrowest available
The spreadsheet connector asks for a permission that allows it to touch only files it created. Not the account's documents, not a folder, not everything — the specific files it made.
That is the single most important thing to check about any connector asking to reach a document store, and it is worth asking of every vendor you grant access to. A connector holding broad access to a drive is one incident away from being the route into every document in an organisation, and the narrow permission costs nothing except the ability to do things it should not be doing anyway.
What AWRA OpsHub does today
- One-way pushes from the workspace into a destination — a calendar, a spreadsheet, a table or a database — with this system as the source of truth throughout.
- Idempotent synchronisation on every connector through a stable key, so re-running updates rather than duplicating and a moved date corrects an existing entry.
- A per-run cap on every connector, so a synchronisation has a known boundary rather than an arbitrary failure point against somebody else's rate limit.
- The manual button and the scheduled run using the same implementation, so a manual synchronisation cannot behave differently from an automatic one.
- A forward-only horizon of six months on the calendar connector, with three deadline types each switchable separately.
- A least-privilege permission on the spreadsheet connector, limited to files it created rather than to the account's documents.
- A configuration check on each connector requiring both halves of its credentials before anything is attempted.
- A result per run reporting how many records were synchronised and by type, with an error where one occurred.
- Daily scheduled runs in the early morning, once across servers and never overlapping.
More we can add to your workspace
- Two-way synchronisation with a stated conflict policy, for the destinations where people genuinely need to edit.
- Continuation past the per-run cap, so a larger workspace completes over several runs rather than synchronising the same first two hundred.
- A record of what each run synchronised, visible in the workspace rather than only as a count.
- A configurable horizon on the calendar connector, for organisations planning further ahead than six months.
- Notification when a connector fails, rather than the failure being visible next time somebody looks.
- More record types per connector, beyond customers and suppliers, and more registers in the spreadsheet export.
Where we point you to a specialist
- We will not write back from a destination without a stated conflict policy. A two-way connector has to answer which side wins on every field, and a connector that guesses produces data loss that looks like an integration working.
- We will not ask for broader access to a document store than a connector needs. A permission limited to the files a connector created costs nothing except the ability to do things it should not be doing, and the alternative makes an integration into a route to every document an account holds.
- What a copy of your records in somebody else's tool is used for is your decision, including whether people may edit it. We will tell you plainly that edits there are overwritten; enforcing that on the other side is not something we can do from here.
Continuation past the per-run cap is the contained piece here, because a larger workspace currently synchronises the same working set repeatedly rather than progressing through it.
Beyond a capped push
The shape is sound and the safety properties are the right ones. What larger workspaces need is completion, and what some destinations need is a route back.
Continuation across runs
A cursor per connector so a large workspace works through its records rather than resynchronising the first two hundred.
Two-way, with a policy
Write-back for the destinations where editing genuinely happens, with an explicit and documented rule about which side wins.
Failure notification
A message when a connector stops working, rather than a silence that looks the same as everything being current.
We publish scope, not dates.
Scope a connectorFive questions to ask about any connector
Which direction does it move data?
A good answer sounds like
A clear answer.
What ours actually is
One way, out. This system is the source and the destination is a copy that will be overwritten.
What happens if I run it twice?
A good answer sounds like
Nothing bad.
What ours actually is
Nothing. Every connector is idempotent through a stable key, so a second run updates the same records.
Is there a limit per run?
A good answer sounds like
A stated number.
What ours actually is
Two hundred records, so a run has a known boundary rather than an arbitrary failure against a remote rate limit.
Does the manual button do the same thing as the schedule?
A good answer sounds like
Yes.
What ours actually is
The same implementation, so a manual synchronisation and an overnight one cannot behave differently.
What permission does it ask for?
A good answer sounds like
The narrowest that works.
What ours actually is
On the spreadsheet connector, access limited to files it created rather than to the account's documents.
Our take
Four properties shared across every connector is worth more than any one connector, because it means you can reason about a new one before reading its code. Push only, idempotent, capped, and identical whether triggered by hand or by schedule — those together produce integrations that are boring to operate, which is the only quality that matters in something running unattended every morning. The trade is honest and worth stating plainly: the destination is a copy and edits made there are lost. Where that is unacceptable the answer is a two-way integration with a written conflict rule, and that is a bigger piece of work than it looks precisely because the rule has to be decided rather than assumed.
Decide whether anybody will edit the copy
It is the only question that matters when choosing a connector, and it is much cheaper to answer before people have started working in a spreadsheet that overwrites itself every morning.
Talk through connectorsFrequently asked questions
Can I edit records in the connected spreadsheet or table?
You can, and the edit will be overwritten on the next synchronisation with no warning. These connectors push one way, so the destination is a copy for reading, charting and sharing. Where people genuinely need to edit in the other tool, that is a two-way integration with a stated conflict policy rather than a push somebody hopes nobody writes to.
What happens if I press "sync now" twice?
Nothing. Every connector is idempotent through a stable key — a calendar event keyed so a moved date updates the same entry, a table record merged on its primary field, a page matched on its title. That is deliberate: a button that is dangerous to press twice is a button nobody presses at all.
Why did only some of our records synchronise?
The per-run cap of two hundred. It exists because the destinations rate-limit, and a bounded run with a known outcome is easier to reason about than an unbounded one that fails at an unpredictable point. These connectors are built for a working set rather than an archive; continuing across runs so a larger workspace completes is the first item on the list of what would be added.
Why does the calendar only show six months?
Because a calendar is a forward-looking instrument. The connector looks a hundred and eighty days ahead and never behind, which keeps it about the near future rather than filling with historical deadlines nobody can plan around. Three deadline types are pushed — order deliveries, approvals coming due and sourcing response dates — each switchable on its own.
What access does the spreadsheet connector have to our Google account?
Only the files it created. It cannot reach your documents, your folders or anything else in the account. That is the single most important thing to check about any connector asking to reach a document store, and it is worth asking of every vendor you grant access to.
How would we know a connector had stopped working?
Today, by looking. Each run reports how many records it synchronised and by type, with an error where one occurred, but a failure does not announce itself. Notification when a connector fails is on the list above, and it matters because a silent connector and a fully up-to-date one look identical from the destination.
