Create/Update Authorization in Dynamic Collection v1.0.0 Help ​

Creates a new authorization or updates an existing one in a specified authorization service, then adds a reference to this authorization in a dynamic collection.

How can I use the Step? ​

You can use the Step to create or update authorizations within an authorization service and link them to a dynamic collection. This keeps your authorizations up-to-date and correctly referenced.

How does the Step work? ​

The Step creates or updates an authorization in a specified service. It then references the authorization in a dynamic collection using the specified authorization key.

Dynamic collection settings ​

This section outlines the parameters for configuring the Step's interaction with dynamic collections:

  • Authorization source: Defines how the Step receives authorization information. You can inherit the dynamic collection name and authorization key from the previous Step or define them manually. Exception: The inheritance option doesn't work with the List Authorization in Dynamic Collection Step.
  • Dynamic collection name: The name of the dynamic collection where to store the authorization reference.
  • Authorization key: The specific key for the authorization.

Authorization settings ​

Set authorization details, including type and service:

  • Authorization type: The type of authorization to create/update. Specific authorization settings are available based on the selected authorization type.
  • Service: The name of the authorization service for which you create/update authorization (e.g., Slack).

Note: We do not recommend storing authorizations with a type different from the dynamic collection's authorization type. Although it is not restricted.

Token settings ​

The section includes an input for the token string used in Bearer HTTP authentication, a scheme that employs security tokens known as bearer tokens. To learn more, see RFC 6750.

OAuth settings ​

OAuth 2.0 allows a third-party app to access an HTTP service on behalf of a user or the app itself. To learn more, see RFC 6749.

OAuth settings include:

  • OAuth app: Name of the authorizer application stored in the authorization service. If you provide a dynamic collection via the Merge field (e.g., {create_dc.collectionName}), you must enter the app ID instead of the app name. The OAuth app ID can be fetched from the authorization service using the List Authorizer Keys (Installer) Step.
  • Redirect service: Determines the redirect behavior post-authorization. You can use default or custom provider flows. For the second option, additional parameters include:
    • Provider redirect flow path: Path used for the OAuth redirect flow. Defaults to authorizer/redirect.
    • Service definition provider flow path: Path used to list defined services for OAuth authorization. Defaults to authorizer/services/list.
  • Scopes: Specifies the level of access that the application is requesting. When updating authorization, provided scopes overwrite existing ones.
  • Authorization URL timeout duration: The time duration after which the authorization URL expires. Defaults to 1 hour.

Basic settings ​

The section contains fields for username and password required for Basic HTTP authentication. According to this schema, credentials are transmitted as username/password pairs encoded using Base64. For more information, refer to RFC 7617.

Conflict handling ​

  • Action on duplicate key: Defines the action to take if an authorization with the same key exists. You can overwrite the existing key, skip the step execution, or add an exists exit to process the conflict.

Merge field settings ​

The Step returns the result as a JSON object and stores it under the Merge field name. To learn more about Merge fields and how to work with them, see our Merge fields guide.

Output example ​

The output varies based on the type of authorization. It includes details about the authorization type, key, service, and collection name. For OAuth authorizations, it also provides an authorization URI. Here are some examples:

For a token authorization:

json
{
  "type": "token",
  "key": "kinde_token_1",
  "service": "__authorization_service_Kinde",
  "collectionName": "Kinde_oauth"
}
{
  "type": "token",
  "key": "kinde_token_1",
  "service": "__authorization_service_Kinde",
  "collectionName": "Kinde_oauth"
}

For an OAuth authorization:

json
{
  "type": "oauth",
  "key": "sf_oauth_one",
  "service": "__authorization_service_Salesforce",
  "collectionName": "Salesforce_oauth",
  "authorizationUri": "https://test.salesforce.com/services/oauth2/authorize?response_type=code&client_id=3MVG9t0sl2...37d457a94bc0"
}
{
  "type": "oauth",
  "key": "sf_oauth_one",
  "service": "__authorization_service_Salesforce",
  "collectionName": "Salesforce_oauth",
  "authorizationUri": "https://test.salesforce.com/services/oauth2/authorize?response_type=code&client_id=3MVG9t0sl2...37d457a94bc0"
}

Error Handling ​

By default, the Step handles errors using a separate exit. If any error occurs during the Step execution, the Flow proceeds down the error exit. For more information, see Error and timeout handling.

Reporting ​

The Step automatically generates Reporting events during its execution, allowing for real-time tracking and analysis of its performance and user interactions. To learn more, see Reporting events.

Service dependencies ​

  • sdk-api v2.17.0
  • access event-manager v2.1.0
  • oauth redirect endpoint provider v2.1.6

Release notes ​

v1.0.0

  • Initial release