Automating Expensify using Okta Workflows

• Introduction
  • Requirements
  • Expensify - Obtain API Secrets
  • Okta Workflow - Summary of the provided Workflow
• Suggestions when deploying

Introduction

Expensify unfortunately does not support lifecycle management using their provisioning integration. However there are ways around that, for example, using the Advanced Employee Updated API that Expensify provides.

However, their API is finicky at times. In an effort to help get you started, I am going to go over our Okta Workflow that helps us keep our employees up to date, including:

• Create/Provision Users in Expensify
• Update User Attributes in Expensify
• Remove & Disable Users in Expensify

Which are missing from the Provisioning Tab. This will not cover:

• Group Push from Okta to Expensify
• Import Groups from Expensify to Okta
• Sync Password

You should be using SAML in Expensify in this example.

Requirements

You should have one of the following:

• An Expensify Account (seems obvious doesn’t it)
• A policy that you will use to test against
  • Note: You could run this in full production, using dry run, but that could be bad.
• A Service Account that has Policy Admin in the policies where you wish to apply users to
• An API User
• An API Secret

Expensify - Obtain API Secrets

1. Go to https://www.expensify.com/tools/integrations/
2. Generate an API key

Okta Workflow - Summary of the provided Workflow

You can find the Okta Workflow that we use at this link.

Update: I have updated the flow to instead use a Call Flow card, rather than a For Each Object card to reduce the amount of API spam. Thanks to Michael P for the heads up.

Going over our workflow, we have three specific entries here:

• 3 Event Flow
  • User Profile Updated
  • User Assigned Application
  • User Removed from Application / User Deactivated
• Child Helper Flow
  • Calls the API and makes determinations baed on data

The three event flows are quite self-contained and self-explanatory. Either the User Removed from Application or User Deactivated cards could potentially work well in this scenario, depending on your needs. While the API Helper Flow is slightly more complex (but also still very much straight forward).

We start by reading the user, and erroring out if the Okta ID, Cost Center, Manager, or Office Country Code does not exist.

Because of the issues with the Google Connections, we will then proceed to wrap our flow in a Try error.

We also want to create a If/Else card to validate that the account is deactivated, and provide a proper output based on the account for the API.

From here then we construct the cards we need for the API:

This pulls the data from the Read User cards and dynamically puts it into the Compose card to then finally send to the API:

There you have it. From here, the API should respond by either creating the employees credentials in Expensify, where they can login via SSO and be ready on the employees first day.

The SVG of the flow can be seen below:

User Profile Updated

Update: Uses a call flow card, rather than for each.

User Assigned Application

Update: Uses a call flow card, rather than for each.

API Helper

Suggestions when deploying

When deploying this specific workflow (if you don’t alter it), here is what I would recommend:

1. Work with your Expensify Administrator / Support
2. Assign everyone the application
3. Do an initial CSV import with all the correct data first
4. Flip on the Workflow entries
5. ???
6. Profit

When doing it this way, you avoid:

1. Generating tons of unnecessary API calls or potential email (if you specify that)
2. Sending employees multiple “You have been added to this policy” emails