Standardized Account Workflows

Background

Account workflows define what Lumos does when it provisions or deprovisions an account on an app. For example, the steps to create a Google Workspace account, or to suspend it and transfer data. Before this release, you configured these workflows separately inside each product: AppStore, Lifecycle Managment, Access Reviews and the Account sidebar. The same app could behave differently depending on where the workflow ran, and keeping them consistent meant tracking down and editing every instance by hand.

Standardized Account Workflows replaces that with one centralized table per app. You define a workflow once under Apps → [App Name] → Account Workflows, then reuse it across every product surface. This article covers where to find the table, how to create and edit workflows, and how to set defaults.

When to use this

• You're standardizing behavior across products. Your team uses Lumos for more than one product, such as AppStore and Onboarding, and you want a single app to behave the same way no matter which product triggers the workflow.

• You've hit configuration drift. You've noticed that similar apps offboard or review differently, or that the same workflow has been rebuilt in several places and the copies have fallen out of sync.

• You're expanding to a new product. When you start using another Lumos product, it reuses the workflow configuration you've already built instead of requiring setup from scratch.

• You're connecting a new app. Lumos auto-generates default provisioning and deprovisioning workflows when an app is connected, giving you a working baseline to adjust.

Prerequisites

• The app must already be connected to Lumos. No new integration or special setup is required. The centralized table is available for existing connected apps.

• You need App Admin permissions for the app. For custom roles, the required privilege is apps.manage.workflows.

Viewing account workflows

1. Go to Apps and open the app you want to manage.

2. Select the "Account Workflows" tab.

The table lists every workflow defined for that app across all product contexts in one view, including the auto-generated defaults. Each row shows the workflow "Name", "Owner", which "Defaults" it's assigned to (for example, Provisioning), and an "Actions" menu. Use "Show Filters" to narrow the list.

Creating or editing a workflow

1. From the "Account Workflows" tab, click the "+" button to create a workflow, or open the "Actions" menu on an existing row to edit it.

2. Set the "Workflow Type" to Provisioning or Deprovisioning.

3. Enter a "Name" and an optional "Description".

4. Under "Workflow Steps", add each step in order. For a manual step, enter the "Instructions" (for example, "add user to the GitHub org") and any "Custom Assignees".

5. Click "Add Step" to add more steps.

6. Click "Save".

Every product references the same definition, so saving a change applies it everywhere that workflow is assigned. If a workflow runs across multiple high-stakes products, test the change in a non-critical context first.

Setting and reusing defaults

Account Provision and Account Deprovision workflows can be set as the default for all products. A default applies to any product surface that doesn't have a specific workflow selected.

• Reuse across products. Once defined, a workflow can be assigned across AppStore, Onboarding, Movers, and the Account sidebar. Define it once, use it anywhere.

• Override with a custom workflow. Any product surface can use a custom workflow instead of the default. Different teams can own different workflow definitions for the same app.

• Update a default. Editing a default workflow immediately updates every product area that relies on it.

Workflow behavior reference

Limitations

• Default workflows can't be deleted directly. Deletion is blocked until you reassign a workflow.

• Some per-product overrides aren't available yet.

Adopting the centralized model

You don't have to migrate everything at once. Existing workflows aren't automatically deleted or replaced, so you can adopt the centralized model incrementally, one app at a time. A practical starting point is a single high-stakes app where workflow drift has already caused an inconsistency. Migrate that app to a default definition, confirm the behavior, then expand to additional apps.

FAQ

Do you have to recreate your existing workflows from scratch?
No. Existing workflows aren't automatically deleted or replaced. You can adopt the centralized model incrementally, app by app.

If you update a shared workflow, does it change immediately across all products?
Yes. All products reference the same definition, so an update takes effect everywhere it's assigned. Test in a non-critical context first if the workflow runs across multiple high-stakes products.

What happens if you delete a default workflow assigned to multiple products?
Deletion is blocked. You're required to reassign a workflow first.

What happens if you delete a shared workflow assigned to multiple products?
The affected product surfaces fall back to the default workflow.

What happens if you update a default workflow?
Every product area without a specific workflow selected uses the new default.

Do you need a new integration or special setup to access the centralized workflow table?
No. The table is available for existing connected apps. App Admins can reach it under Apps → [App Name] → Workflows.

Can different teams own different workflow definitions for the same app?
Yes. Any custom workflow can be used instead of a default workflow for a given product surface.

What role is required to update workflows?
App Admins can update workflows for their apps. For custom roles, the privilege is apps.manage.workflows.