About the building blocks of a connector
This is an Early Access feature for existing Workflows users. To enable it, use the Early Access Feature Manager as described in Manage Early Access and Beta features.
Connectors define operations that can be enacted by Okta Workflows in third-party applications or Okta itself. A connector can have events or actions, or both, that contain up to four main components:
parameters (options in the card interface)
For a full list of connectors that are available in Workflows, see Connectors.
Cards (or "methods") are the primary components of any connector. Cards can be events or actions. For example, Salesforce (the connector) has methods for New Record (an event) and Transfer Leads (an action).
To test or run a flow, a user must create a connection to a connector's third-party service for any new card that is added to Workflows designer. The process of creating a connection depends on the application and the auth type required by the service. Users can create multiple connections to the same service.
Basic authentication is a simple username and password scheme built into the HTTP protocol. Workflows sends HTTP requests with the Authorization header containing the word Basic followed by a space and a base64 encoded string of username:password.
OAuth 2.0 is a protocol that allows you to grant limited access to resources on a third-party site without having to expose your credentials to Workflows.
Custom authentication allows you to collect any information from the user that needs to be included in an API request. A common example is the use of API Keys that get managed in a third party system and are passed into an HTTP request along with other header object keys and values.
Options are values selected at design time (as opposed to changing at runtime) that are included in every call to the service regardless of changing inputs.
Static options are fields that accept an input from the flow builder at design time. These can be basic text, number, or boolean values, dropdown fields, and so forth, that do not require a separate call to the service to populate.
Static inputs are defined by the developer and are 'hard coded' into the connector definition. These fields can be marked as required, which will display the fields in red and not allow the user to save a flow until those fields are populated.
Data types on input cards are indicated with a small icon to the upper right of the field. Clicking on that icon displays the data type in text form. Available data types include Text, Number, True/False, Date & Time, Object, and File. This also applies to Outputs.
To change the Display Name string or to add or modify text in the Help Text field, click the Customize link in the dropdown for a field's data type. You can also make the same change for any output field.
Help Text can be added by the developer, but hasn't been regularly used in the platform. When Help Text is added, a help indicator displays to the left of the input. Hovering over that indicator displays the message. This also applies to Outputs.
Static Outputs are defined by the developer and are 'hard coded' into the connector definition. The values returned can be used when interacting with subsequent functions or actions.
Dynamic fields return different values depending on the account used when creating a connection. These are often used when end users of an application can add their own record types or fields. They are different and much more flexible than static fields in that they are not tied to the definition of a connector and will differ based on the customized data sets that are specific to a third-party service account. In the Salesforce example, Record Types can be defined per instance and differ per account.