Course 11 · Connectors and integrations

Migration is an event. Currency is a pipeline. This is where you wire systems that keep your estate true.

By the end of this lesson you will know what each connector is for. They fall into families: paper coming in, spend and usage flowing in, and your data flowing back out.

The catalog opens with the whole picture. Every connector here stores its credentials encrypted, asks for read-only access where it can, and logs every sync.

First family, getting the paper in. Half of these are private email addresses. The rest connect where contracts are already signed, DocuSign, Ironclad, and folder watch.

Start with the cheapest rail. Forward a vendor proposal to your private intake address, and it lands as a tracked contract, read as its document.

The second address is for live negotiations. Forward the vendor thread onto the deal record, and the reply can be drafted right there.

The third checks the money. Forward an invoice and its lines are read against what the contract says, so billed and contracted are compared as bills arrive.

The fourth turns email into intake-to-procure. A teammate raises a purchase request by mail, and it drops straight into triage.

By the end of this lesson you will bring Vera to where your team already talks. Ask in Slack or Teams about a price, a clause, or a renewal, and the answer comes back with every figure tagged to its source. An owner connects it once. Each person then opts in per alert type.

This lesson adds intake with no forwarding at all. Point a watch at a folder in Drive, SharePoint, or Box, and saving a signed contract there files it here automatically.

By the end of this lesson you will govern access from your own identity provider. Single sign on makes Okta, Entra, or Google the front door.

One place people sign in, one place they are cut off. Access follows employment, not a list you maintain by hand.

SAML is the sign-on half. You paste the platform's details into your provider, paste its metadata back, set your email domain, and test before you enforce. When you do enforce, owners keep a password as break-glass, audited.

SCIM is the provisioning half. Your identity provider creates, updates, and deactivates accounts here, so your joiner and leaver process is the single source of truth. A person added there appears without an invite. Deactivated there, their access here ends.

You can go further and map identity groups to roles. Join a group, gain the role; leave it, lose the role. Ownership is never assigned this way, by design.

The last lesson is for the technical buyer. Everything is reachable over a REST API, and over MCP so your AI assistants can query it.

One call proves the model. Ask for your contracts with your key, and your data comes back, only what it allows.

An owner creates a key here. You see it once, so store it in your secrets manager immediately.

Two questions before you go. One, what does single sign on govern that a password list cannot? Two, why is an API key server-side only?

If either is fuzzy, replay it. Now you: connect one source this week, an email rail takes minutes. Next, Course 12, Data health.