Workflows Tips #17: Exporting a Flow, When to Use Tables, and Online Meetup Reply
Welcome to another Okta Workflows Tips post. Read all previous tips.
In this post:
- Exporting a flow
- When to use tables
- Meetup Replay: Everything You Need to Get Started with No-Code Workflow Automations for Identity
Exporting a flow
This tip is from Gabriel Sroka, Okta expert and developer of the rockstar Chrome extension. Gabriel also hangs out in the MacAdmins #okta-workflows Slack community.
When you share Content with the Export command, all account information is removed.
From Workflows docs:
When you share Content with the Export command, all account information is removed. You’re just sharing the logic of the flows and the schema of tables. The recipient will have to assign new accounts in order to use the flows. If you import the same flows or tables into their original instance, the existing connections may be reapplied to the cards in those flows.
https://help.okta.com/wf/en-us/Content/Topics/Workflows/build/export-import-flows.htm
But, if you have hard-coded API tokens on anything like that, please remove those as they will not be removed during export.
One more thing. You export a flow with an Okta connection and share it with someone. When that person imports the flow and they have an existing Okta connection, that connection might be chosen automatically. It might seem like your connection informaiton is there but it’s not. Your connection information was removed during export. Something to keep in mind.
Even if a connection was chosen, you can always create a new connection:
Using tables
Gabriel Sroka, AJ Ahrens (Okta), Bryan Barrows (Okta), and Brent Garlow (Okta) contributed to this tip.
Event though tables can store up to 100k rows, tables should be used as a fast cache/transitory place for storing small amounts of data. Tables are not ideal for storing a lot of data, or sensitive data. It’s not really a database. And, you should consider clearing the table once its data was persisted or no longer needed.
Some recommended use cases for tables:
- Store data for different flow runs
- A flow saves data into a table to be read when it runs again
- Store data for different flows
- A flow saves data into a table to be read by a different flow
- Look-up tables
- Information such as country and country code (see image above)
- Basic reporting
- Keep track of successful and failed flow runs
- How many times “something” happened
- Save any report data into a table to be later exported into Google Sheets and clear the table
While it is recommend using tables for relatively short-term storage, there are use cases where data can stored outside of transactional storage between flows. For example, log a user event like created, then check the table to see if 90 days has past.
This is general advice, there are other cases where tables can be used. Let us know in comments if you have other use cases.
Meetup Replay: Everything You Need to Get Started with No-Code Workflow Automations for Identity
We hosted Everything You Need to Get Started with No-Code Workflow Automations for Identity online meetup.
Watch the replay below to learn:
- What’s on the dashboard, an overview
- How to use actions and functions
- Four ways to start a flow
- How to map data from one card to another
- Using tables to store flow data
- Testing a card, testing a flow
- How to use connections
- Using templates
- Connecting to a custom API endpoint
- Hands-on example building a flow
Two resources to help you learn more:
📌 Try this step-by-step getting started tutorial: Build Your First Automation With Okta Workflows: Notify When User Is Suspended.
📌 All the Workflows resources (docs, tutorial, office hours, templates, office hours and more)
Related
Published on Java Code Geeks with permission by Max Katz , partner at our JCG program. See the original article here: Workflows Tips #17: Exporting a Flow, When to Use Tables, and Online Meetup Reply Opinions expressed by Java Code Geeks contributors are their own. |
