Docs

Connect Google Cloud

A service account with Viewer, its key pasted once, and what the cloud API can and cannot see.

A Google Cloud project holds scheduled jobs, functions and services that read and write the CRM. The connection enumerates them and works out what starts each one.

Credentials

The collector reads your project as a service account you make for it, with the Viewer role and nothing else. The connect form walks through it, and none of it needs a terminal:

1. In the Cloud Console, open IAM & Admin → Service Accounts for the project and press Create service account.
2. Name it tanglemap-collector and continue.
3. Under Grant this service account access to project, choose Basic → Viewer, then Done.
4. Open the account, then Keys → Add key → Create new key → JSON. A file downloads.
5. Paste the whole file into the form and connect. The form checks that the key can see the project before it saves anything. Delete the download.

An existing service account works as well, as long as it has Viewer on the project. The project id field on the form is optional: the key names its project, and you only fill it in to read a different project the same account can see.

The key is stored with the workspace's other credentials, the same way a HubSpot token is, and is used only to list what runs. Revoke it any time by deleting the key or the account on the same Console page.

If the form refuses the key

• Not a JSON key file, or lacks private_key: paste the whole file, from the opening brace to the closing one. A key copied from the Console's table rather than the downloaded file is only the key id.
• Cannot see the project: the account has no Viewer on that project yet, or the grant is a minute old. Check the project's IAM page for the account's address, then try again.
• Google could not check the project: the Cloud Resource Manager API is disabled in the project that owns the account. Google's message carries the link that turns it on.

Running locally you may leave the key blank, and the collector uses the gcloud application-default credentials already on the machine.

What the API can see

Cloud Run services, Cloud Functions and Cloud Scheduler jobs, plus the Pub/Sub wiring between them. From that the collector knows what runs and what starts it: a scheduler job targeting a service, a push subscription pointing at one.

What the API cannot see is which CRM fields the code touches. Those live in source. So a Google Cloud system in the graph reads as "we know what runs, not what it touches" until a repository connection or a manifest fills that in, and its coverage pill says so: automations complete, edges unknown. That is honest, and it is the reason the collector produces no edges of its own rather than guessing.

Filling in the edges

Connect the repository that holds the code (Connect GitHub), or add an automation.yaml manifest to it. A manifest's system and system_name should match the project so the two connections describe one system rather than two.