Setting up workflows

For: Owners, Admins, and tool owners. Takes about 10 minutes.

What this does

A workflow is the list of steps Stacktic runs when someone makes a request. "Check their training, get the owner's approval, then create the account" is one example. Once a workflow is on, employees can ask from Slack or the tool registry, and Stacktic handles the rest:

• it messages approvers;
• it waits for answers;
• it creates accounts where it can;
• it tells the requester how it went.

There are two kinds:

• Access workflow. Runs when someone asks for access to a tool you already manage. Each tool account gets its own.
• New-tool workflow. Runs when someone uses the registry's Add a tool form to ask for a tool you don't use yet. Your company has one.

Before you start

• For an access workflow, the tool needs at least one account. If it has none, add one from the tool's Overview tab first.
• To edit an access workflow, you need to be an Owner, Admin, or User.
• To edit the New-tool workflow, you need to be an Owner. It lives in Settings.
• For the New-tool workflow to get requests, Request a new tool has to be on in Settings → Tool Registry.

Where to find them

Access workflow: open the tool, then the Workflow tab. Each account has its own Access requests card.

• The tool's Lifecycle card also has an Access requests row showing On or Off. It links straight to that tab.
• The tab shows a green dot when any account's workflow is on.

New-tool workflow: go to Settings → Tool Registry. Under Adding a tool, find the New-tool requests card.

Building a workflow

1. On the card, click Set up (or Edit, if it already has steps).
2. Under Add a step, pick a step and click Add. Repeat until you have the steps you want. Use the ↑ and ↓ buttons to reorder steps, and × to remove one.
3. Fill in each step's settings. The step catalog below describes them.
4. Optionally, write your own Messages to the requester. These are the four messages sent when a request ends: complete, declined, doesn't go through, and something goes wrong. Leave one blank to use the default shown in the box. Two exceptions:
   • A cancelled request always gets the standard wording.
   • On a New-tool workflow with Activate the tool, the complete message isn't sent. The requester is told the tool is in the registry instead.
5. Tick Run this workflow to turn it on.
6. Click Save workflow.

Above the editor, a diagram draws the workflow as connected boxes. It starts with Access requested (or New tool requested), then shows your steps, then Done.

• Each step box shows who it goes to.
• A step that reaches nobody shows what it does instead. Create the account shows the standard role it uses, and Ramp card shows how often its limit resets.
• If a step has a condition, its box carries an amber "Only if…" tag.
• If a save finds a problem, the step is ringed in red. The message under it says what to fix.

Turning a workflow off doesn't affect requests already running. They finish with the steps they started with.

Testing a workflow

You can see what a workflow would do for a particular person. You can do this before you turn it on, or any time after. Testing doesn't start a request: nothing is sent, created, or recorded.

1. On the card, click Test this workflow. The button appears once the workflow has saved steps. It tests what's saved, not unsaved edits.
2. Click Choose a person and pick anyone at your company.
3. Read the result. Each step says what would happen for that person. Then the box at the bottom says how the request would end and what they'd be told.

What each step checks:

• Training complete reads their real training records, just as a request would.
• Approval and Manual setup name who would be asked. The test assumes they say yes and carries on.
• Create the account asks the tool to plan the account without creating it. So it can tell you if they already have one.
• Message the requester shows the message as they'd get it. It also says if the message couldn't be delivered.
• Ramp card checks that Ramp is connected and the person is active in Ramp. The amount isn't known until someone approves.

When a step would stop the request, the steps after it show as Not reached. Click Assume this passed to see the rest of the workflow anyway. That helps, for example, for someone who hasn't done their training yet. Click Run again after you fix something.

The New-tool workflow has no real tool request to test against. So the test shows the tool as "the requested tool", and assumes each step's condition is met. A step sent to the tool's primary owner or operational contact can't name anyone, since the tool doesn't exist yet. See the warning about those targets under "Who gets each step".

Testing uses the same permission as editing: anyone who can edit the workflow can test it.

The step catalog

Message variables. Messages can use {{tool}}, {{first_name}}, and {{instructions}}. A variable is a placeholder that Stacktic fills in when it sends the message. They work in the Message the requester step and in the four end-of-request messages. {{instructions}} is the account's access instructions. If there aren't any, it's "No access instructions have been written yet."

Required documents. An approval can require documents. Then its Approve button is blocked until the tool has a current, unexpired document of each type you picked, on its Docs tab. The approver is told what's missing. Reject is never blocked. See Managing vendor documents.

Training. Training complete needs an HR connection that reads training records. Today that's BambooHR. If none is connected, the step tells you so.

Who gets each step ("Send to")

Approval and Manual setup both have a Send to field:

• Primary owner (the default)
• Operational contact
• A team: one of your teams from Settings → Teams
• Specific people: up to 20
• A Slack channel: the card is posted there. Stacktic can't tell who is in a channel. So only someone who can see the Requests page can answer it. On an access workflow, the tool's primary owner can answer it too.

On the New-tool workflow, don't use Primary owner or Operational contact. The tool being requested is brand new, so it usually has no owner yet. Any owner it does have is often the requester, who can't approve their own request. A step with nobody to ask ends in an error. Pick a team, specific people, or a channel instead.

People a step is sent to get a card in Slack. If they also sign in to Stacktic, the same step shows on the Requests tab of their My Tasks page.

A few rules hold no matter who you pick:

• The requester is never asked to approve their own request, even if they're the tool's owner.
• On the New-tool workflow, only Stacktic members who manage tools can approve.
• Anyone who can see the Requests page can answer any step, whether or not it was sent to them.

Conditions (New-tool workflow)

On the New-tool workflow, each step can have a condition. A condition is a rule that decides whether the step runs. Tick Only run this step if… and choose what it Depends on:

• Tool origin: run it only for a Vendor tool or only for an Internal tool.
• An answer on the intake form: pick a Question. Then choose when the answer Is answered or Is exactly a value you type. "Is exactly" ignores capitals and spaces at either end.

When a condition isn't met, that one step is skipped and the request moves on. The requester isn't told about skipped steps.

Things to watch for:

• Exact matches are literal. Say finance approval runs only when "Does it cost money?" is exactly "Yes." Then an answer of "yes, $20/month" skips it. Keep yes/no questions short, and say so in the question's wording.
• Deleting a question makes any step that depends on it always skipped. The diagram flags it.
• Two questions with the same wording can't be told apart. So Stacktic won't let you save a condition on either one.
• Activate the tool can't have a condition. A Ramp card must have the same condition as the approval that sets its amount. Or that approval must have no condition at all. That way a card is never issued when its approval was skipped.

Access workflows don't offer conditions. An access workflow belongs to one tool, so there's nothing about the tool that could vary.

The New-tool workflow and the Pending tool

When someone asks for a new tool, Stacktic adds it as a Pending tool straight away. The New-tool workflow runs alongside it. Three rules tie the two together:

• Activate the tool is what makes it Managed. A workflow without that step ends as complete, but the tool stays Pending until someone reviews it by hand. The requester gets the "complete" message at the end of the workflow. They get the "it's now in the tool registry" message only once the tool is activated.
• Rejecting at an approval archives the tool. The requester gets the declined message with the approver's reason.
• Deciding the tool by hand cancels the workflow. Someone might activate, archive, or delete the Pending tool, or move it to Watching, while a request is still running. Then the request is cancelled. The requester gets the usual approved, declined, or "keeping an eye on it" message instead.

While the New-tool workflow is on, its approval card replaces the usual announcement in your signals channel.

Turning on Create the account

Create the account only works when two things are true: the tool's integration can add users, and you've allowed it to. Today that's Help Scout and Tailscale.

Any Owner, Admin, or User can turn it on.

1. Open the tool and go to its Integration tab.
2. Find Automated user creation and click Turn on.

The section tells you its state.

• "On — during an access-request workflow, Stacktic can add this person to…" means you're set.
• Unavailable means the vendor plan or the connection doesn't allow it. A connection that wasn't made by a vendor admin needs to be reconnected as one.

Stacktic checks this when you save a workflow that's on. If the account has no connection, or Automated user creation is off, the step is marked with what to fix. It might also stop working later, while a request runs. Then the step ends in an error rather than failing the requester. Fix the connection, then retry the step from the Requests page.

Some vendors send a one-time join link instead of creating the account outright. In that case, Stacktic DMs the link to the requester.

The Requests page

Requests in the sidebar shows every access and new-tool request, and where each one is. Owners, Admins, and Users all see it. The sidebar badge counts open requests.

The table shows Requester, Tool, Type (Access or New tool), Source (Slack, Registry, or Web), Status, Progress, and Started. You can filter by status, type, tool, or requester, or search. The list updates live as requests move.

The statuses are:

• Running
• Waiting: on a person
• Completed
• Rejected
• Failed: a check failed or a step errored
• Cancelled

Open a request to see each step's outcome, who it's waiting on, and who acted. From there you can:

• Answer a waiting step yourself, even if it wasn't sent to you.
• Cancel request, with an optional reason. The requester sees the reason.
• Retry step. This appears when a request stopped because a step errored. Fix the cause first. You can retry as often as the step errors.

Request on someone's behalf starts an access request for another person. It runs through that tool's access workflow as if they'd asked, and records you as the one who started it. The button only appears when at least one tool has an access workflow on.

Troubleshooting

Frequently asked questions

Does every tool need an access workflow? No. Without one, nothing changes. Employees see the tool's owner and admins, and contact them as before.

What does the requester see? A one-line summary of the steps before they ask, then a Slack DM at the end. Some steps send DMs in between, like Message the requester and Create the account's join link. See Requesting access to a tool and Requesting a new tool for their side of it.

If I edit a workflow, what happens to requests already running? They keep the steps they started with. Your changes apply to new requests.

Can a tool's primary owner answer requests for their own tool? Yes, when a step is sent to them. They can't approve a request they made themselves.

See also

• Roles and permissions
• Primary owners vs. operational contacts
• Connecting Help Scout to Stacktic
• Connecting Tailscale to Stacktic
• Connecting Ramp to Stacktic