Connecting External Services
Connect Slack, Google Calendar, GitHub, email and webhooks so an automation can act in them — how each one authenticates, and what to do when the service you want is not listed.
A workflow that only reads and writes inside LumaVista never needs a credential. The moment you want a step to post to Slack, file a GitHub issue, put a block in your calendar or send an email, LumaVista needs permission to act in that service on your behalf. Connecting is how you grant it.
This page is about connecting: where the button is, what each service asks for, and what to do when the service you want is not in the list. What a connected service is then allowed to do without asking you first is a separate subject with its own rules — see Unattended Actions and Approvals.
Availability. Connectors are part of workflow automation, which is a gated capability — it is available where your deployment has enabled it. Which services you can connect is a second, independent question, answered further down. If you do not see Workflows in the sidebar at all, ask for it on the contact page.
Where connecting happens
There is no separate integrations wizard. You connect at the point of use, inside the step that needs the connection.
- Open Workflows from the sidebar, then open or create a workflow.
- Add a Connector step.
- Choose the service. The step shows its current status: Connected or Not connected.
- Click Connect.
What happens next depends on how that service authenticates.
What each service asks for
| Service | How you connect | What a step can then do |
|---|---|---|
| Slack | Sign in to Slack in a popup and approve the requested access. | Send a message to a channel; list channels; read recent channel history. |
| Google Calendar | Sign in to Google in a popup and approve the requested access. | Read events in a window ahead of now; create or reuse a LumaVista-owned calendar; create, update and delete blocks in that calendar. |
| GitHub | Paste an access token you generate in GitHub. This is not a sign-in flow. | Create an issue; add a comment to an issue; list issues; read repository metadata. |
| Enter your SMTP host, port, username and password. | Send a plain-text message. | |
| Webhook | Paste a bearer token, if the receiving system needs one. The target address and an optional signing secret are set on the step itself. | Post a payload to an address you control. |
Signing in and pasting a token are not the same trust model, and the difference is worth a moment. Slack and Google Calendar use a sign-in flow: you approve a named, limited grant on the provider’s own consent screen, LumaVista never sees your password, and you can withdraw the grant from the provider’s side later. GitHub authenticates with a token you create yourself, which means you choose its scope — grant the narrowest access that covers the actions you actually intend to use.
The sign-in flow, step by step
- Click Connect. A popup opens on the provider’s own site.
- Sign in there if you are not already signed in, and read what is being requested.
- Approve. The popup closes by itself and the step’s status turns to Connected within a few seconds.
Your tokens never reach the browser. The exchange happens on the server; what comes back to the page is the connected-or-not status and nothing else.
Four things can interrupt this:
- Your browser blocked the popup. Allow popups for LumaVista and click Connect again.
- The provider opened in the main window instead of a popup. You land back on Settings → Integrations with a banner saying whether it worked.
- Your session is locked. The credential is written into your own encrypted area, so it cannot be stored while your session is locked. Unlock and try again.
- You declined on the provider’s screen. Nothing is stored. Start again whenever you are ready.
When the service you want is not there
Two different absences, with two different answers.
The service is listed, but Connect opens a paste-credentials form rather than a sign-in popup. Your deployment has no sign-in configuration for that provider. LumaVista treats a provider whose sign-in credentials are not configured as absent rather than half-configured — there is deliberately no broken half-flow to fall into, and no button that spins forever. You can still connect by pasting credentials where the service supports that.
The service is not listed at all. The set of connectable services is fixed by the release, not by your account, so there is no setting that would reveal it. Tell us which one you need on the contact page. If the service can be reached over plain HTTP, the Webhook connector is often the answer in the meantime.
Staying connected
Access tokens expire. Before a run uses a connector, LumaVista renews an expired token in the background, and you never see it happen.
When renewal fails, the stored credential is deleted and the step goes back to Not connected. That is deliberate. A dead credential that keeps being retried produces a run that fails in a confusing way every night; an obvious disconnection tells you exactly what to do. Click Connect again and the automation resumes.
Two more controls sit next to a connected service:
- Test makes one live call and tells you whether it worked. Use it after connecting, before you schedule anything.
- Re-configure replaces the stored credential. This is what you use after rotating a token or changing an SMTP password.
Credentials are per person, not per workspace. They live in your own encrypted area, one set per service. A colleague connecting Slack does not connect it for you, and yours are removed with the rest of your data if you delete your account.
What connecting does and does not authorise
Connecting grants a capability. It does not grant permission to use that capability while you are not watching.
Every connector action is classified by one test: does somebody outside your account now see something they did not see before?
- Listing channels, reading channel history, listing issues, reading a repository, reading your calendar — these are reads. Nothing leaves.
- Sending a Slack message, creating an issue, adding a comment, sending mail, writing a calendar block — these are sends, and a send is gated. The automation pauses and shows you exactly what it is about to do.
Both of the switches that would let a send happen unattended are off by default, and they have to be turned on separately. That whole subject — the three approval choices, what each one actually releases, and how a standing release is bounded — is Unattended Actions and Approvals. Read it before you schedule an automation that posts, mails, or writes to a calendar.
Related guides
- Building Workflows — where a Connector step sits among the other step types
- Triggers and Scheduling — running one of these workflows on a schedule or an event
- Unattended Actions and Approvals — what a connected service may do on its own