Dark Light

Automating Expensify using Okta Workflows

Home / Blog / Automating Expensify using Okta Workflows

Published: May 8, 2022 / Last updated: May 9, 2022 / By Andrew Doering

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.

okta-workflows-1.png

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

okta-workflows-2.png

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.

okta-workflows-2.png

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

okta-workflows-2.png okta-workflows-2.png

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

okta-workflows-2.png

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

User Okta Profile Upd... Context For Each

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

User Assigned Application

User Assigned to Application Context For Each

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

API Helper

Helper Flow Read User Comment Return Error If Continue If Continue If Continue If Comment Read Column Comment Find Random Integer Wait For Continue If Because Headers don't... Comment Read Row Comment Comment Return Error If Error true false Compose Compose Now Expensify API - URL UserID UserSecret Comment Construct Expensify API - Body Expensify API - requestJo... Compose Post

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