Connectors - Synthreo Pylon

What a connector is

A connector is an authorized connection to an external system - Microsoft 365, Linear, GitHub - that an automation can act through. Connecting one is a per-user act of authorization, and that single fact drives everything else on this page.

Whose credentials the run uses

It depends on how the connector authenticates, and that is the first thing to establish, because the rest of this section only applies to one of the cases:

Auth method	Whose credentials the run uses
Per-user OAuth	The execution owner’s - each person authorizes their own account
Each user provides their own key	The execution owner’s, same as above
Shared OAuth	One credential shared by the whole company - no per-user identity
Shared API key for the org	The admin-managed key, the same for everyone
Client credentials (no sign-in)	Unattended by design; no person is present when it runs
No auth required	Not applicable

The rest of this section is about the per-user cases. On a shared or client-credentials connector there is no run-as identity to get wrong, and the publish-time refusal below does not arise.

On a per-user connector, a company automation does not run on the author’s credentials. It runs on its execution owner’s - the run-as user named when the automation was created.

This catches people out because the automation works while you test it and fails the moment it is published:

• You bind a connector from your list.
• The automation names someone else as its execution owner.
• Publish is refused - the run would not have that connection.

The refusal is deliberate and it is the good outcome. The alternative is discovering it on the first scheduled run at 3am, against a live inbox.

Bind only connectors the execution owner has authorized. You can list theirs before you build, which means the handoff you give them names exactly what they still need to connect, rather than finding out afterwards.

Delegated administrators can look but not bind

If you are administering another tenant by delegation, the execution owner’s connector list is advisory. You may read it to plan the handoff; a delegated connector binding is refused. There is no way to substitute your own connection for theirs.

The connection has to be healthy, not just present

The execution owner having a connector is not the same as that connector being usable. A connection carries a state, and binding an unusable one publishes nothing - the same check runs at publish time.

State	What it means	Who fixes it
needs_reauth	The authorization lapsed	The owner re-authorizes
needs_credential	Never finished connecting	The owner completes it
needs_setup	Never finished connecting	The owner completes it
quarantined	The connection broke	The owner repairs it
needs_repair	The connection broke	The owner repairs it
disabled	An administrator turned it off	An administrator

This table lists failure states, not every state. A healthy connection reads as ready or connected and needs nothing done to it. So an unfamiliar value does not automatically mean broken - it means unknown, which is a different thing. Report an unrecognised state to the owner verbatim rather than guessing either way; the list of failure states is explicitly not exhaustive, so a real failure can arrive under a name that is not written down here.

There is one more case worth knowing: a connection can read as ready and still fail the check. When that happens the failure names the specific fields responsible - a pending re-authorization, a disabled connection, or a connector disabled in the catalog - and those fields are what to act on, not the summary state.

The default that stops unattended runs

A side-effecting action defaults to asking, and a scheduled run has nobody to ask

Every connector action carries a consent setting - auto, ask, or deny. Actions with a side effect in the outside world - send an email, post a message, create a ticket - default to ask.

That default is right for someone working interactively and wrong for a schedule. An unattended run hits an action set to ask, finds nobody to approve it, and fails with “requires approval”. It does not act, and it does not quietly succeed either.

This is one of the most common reasons a correctly built scheduled automation appears to do nothing. The trigger fired, the run started, the logic worked - and the delivery leg stopped on a consent prompt with no one there.

If a scheduled automation needs to deliver something, change that specific action before you rely on it. Setting it is a deliberate act, which is the point: you are recording that this connection may act unattended.

The three settings are the same wherever they are exposed, though the labels differ by surface:

Setting	Shown in ThreoAI as	Behaviour
auto	Run freely	Runs without asking. The one a schedule needs
ask	Ask first	Requires approval. Safe interactively, fatal unattended
deny	Off	Blocks the action entirely

Where to change it. Consent lives on the connection and is changed by whoever administers that connection - which, on a per-user connector backing a company automation, is the execution owner rather than the author.

The surface differs by product, and only one of them is documented today: ThreoAI exposes it in the connector detail pane under Studio → Capabilities → Connectors, set an area at a time or tool by tool. That is ThreoAI’s surface, not a route into a Pylon automation’s settings - Expert actions, for instance, are configured on the Expert rather than through Connectors. If you cannot find where to change it for the connection your automation uses, ask whoever authorized it; that person can, and going through them is the correct path anyway when the credentials are not yours.

Consent is set per action on a connection and applies to everything using that connection, unless something narrower overrides it for one use.

How a connector is identified

A connector connection is addressed by two numbers together - an install id and a connection id. Neither identifies it alone, and both are positive identifiers issued by the platform.

You will rarely type these by hand, but the pairing explains an error worth recognising: a mutation that comes back describing a different pair than the one asked for is rejected rather than applied. That is the system refusing to act on a sibling account’s connection, and it fails closed on purpose.

Related

• Schedule an Agent - where the consent default bites
• Agent Configuration Reference - the Tools tab and what an agent may use
• Pylon Overview