Create a configuration template

  • Release version: Australia
  • Updated March 12, 2026
  • 7 minutes to read
  • Create a template that defines the inputs required to set up a spoke. Set static key-value pairs to create records and set values that apply to every integration. Set dynamic key-value pairs to gather user input and set field values that may vary. Using this template, admins and flow designers can set up the spoke from a single form.

    Before you begin

    Role required: admin

    Procedure

    1. Navigate to All > IntegrationHub > Connections & Credentials > Configuration Templates.
    2. Select New.
    3. Select the type of configuration template that you want to create.
      Configuration typeDescription
      HTTP Connection with OAuth Authorization Code grant type Creates a template to register the third-party system as an OAuth provider using an authorization code.
      HTTP Connection with OAuth JWT Bearer grant type Creates a template to register the third-party system as an OAuth provider using a JSON Web Token.
      HTTP OAuth with Client Credentials grant type

      Creates a template to integrate with a third-party application via the OAuth 2.0 authentication that uses the client credentials grant type.

      HTTP Connection with OAuth Client Credentials grant type (External Storage)

      Creates a template that enables the sending of OAuth token request that comprises client credentials stored by an external storage to an OAuth server via the MID Server.

      HTTP Connection with Basic Auth Credential Creates a template to integrate with the third-party system using basic authentication.
      HTTP Connection with API Key Credential Creates a template to integrate with the third-party system using an API key.
      Other Configuration Creates a blank template, enabling you to set up a template for custom authentication.
    4. In the Name field, add a name to identify the template.
    5. In the Default Data Template field, make any required changes.

      This field sets static information that applies to every integration. For example, you can set the API and token URL if the value applies to every integration.

      These objects in the default data template are required:

      • credential: Creates a credential record with the required fields.
      • connection: Creates a connection record with the required fields. Access connection attributes using the extended_attributes child object. For example:
        "connection": {
                    "extended_attributes": {
                        "api_version": "v1"
                     
                     },
                "connection_url": "https://<provider-domain-name>.com",
                "name": "Spoke Connection",
                "table": "http_connection"
            }

      You can use the additional object to set up data for a custom table, and use the post processing script to insert the data into the table.

      Note:
      In the default data template for the OAuth Authorization Code grant type, the values for the oauth_entity_profile_scope and the oauth_entity_scope keys must match. In the following example, both keys have the Read user's email value.
      "oauth_entity_profile": [
              {
                "grant_type": "authorization_code",
                "name": "<provider-name> Profile",
                "default": true,
                "oauth_entity_profile_scope": [
                  "Read user's email"
                ]
              }
            ],
            "code_challenge_method": "S256",
            "type": "consumer",
            "oauth_entity_scope": [
              {
                "oauth_entity_scope": "Read user's email",
                "name": "email"
              }
            ],
    6. In the Dynamic Data Schema field, make any required changes.

      This field Defines the information that the user must complete to set up the integration. For example, you can add user name and password key-value pairs to gather user-defined values.

      Fields in the dynamic data schema include these properties:

      • name: The field that the user's input maps to. For example, to map user input to the Connection URL field in the Connection record, enter connection.connection_url.
      • label: The field label that the user sees when completing the template.
      • type: The field type. Make sure that this data type matches the data type of the field you are mapping the value to.
      • defaultValue: Optional. The field's default value. If no default is provided, the hint displays.
      • hint: Optional. Hint text to display when there is no default value.
      Note:
      If setting up a template for OAuth JWT Bearer grant type authentication, you may want user input for a single key-value pair in the jwt_claim_validation array. You can refer to a single key-value pair in the dynamic data schema by referring to its index in the array. For example, your default data template might include this snippet.
      "jwt_claim_validation" : [ {
              "name" : "iss",
              "is_standard" : true,
              "data_type" : "string",
              "value":"<docusign-iss-claim>"
            }, {
              "name" : "sub",
              "is_standard" : true,
              "data_type" : "string",
              "value":"<docusign-sub-claim>"
            }, {
              "name" : "aud",
              "is_standard" : true,
              "data_type" : "string",
              "value":"<docusign-aud-claim>"
            }, {
              "name" : "scope",
              "is_standard" : false,
              "data_type" : "string",
              "value" : "signature impersonation"
            } ],

      Refer to the iss key-value pair using the item's zero-based index: credential.jwt_provider.jwt_claim_validation[0].value.

    7. Optional: In the Post Processing Script field, add a script that c Creates additional records required by the integration. For example, if your spoke includes custom tables, you can create records in those tables based on user input in the configuration template. This script executes after the connection and credential records are created.
      The post-processing script has access to these global objects.
      Global object Description
      aliasId Sys_id of the alias record from the Connection & Credential Alias [sys_alias] table.
      connectionSysId Sys_id of the connection record created by the template.
      jsonDefaultData JSON content from the Default Data Template field in String format.
      jsonDynamicData JSON content from the Dynamic Data Template field in String format.
    8. In the Pre-Edit Script field, add a script to pre-populate the additional fields when you edit a connection.

      This script returns an array of objects. Each object has a name-value pair for populating the additional fields. For example, if the connection requires fields that are in a custom table, you can map these fields to the custom table.

      The Pre-Edit Script has access to the following global objects:
      Global object Description
      aliasId Sys_id of the alias record from the Connection & Credential Alias [sys_alias] table.
      connectionSysId Sys_id of the connection record created by the template.
      jsonDefaultData JSON content from the Default Data Template field in String format.
      jsonDynamicData JSON content from the Dynamic Data Template field in String format.
      Each object in the script has the following properties:
      • name: Name of the custom field to specify the value in the connection.
      • value: Value that you want to map to populate the custom field. You can map the field either by using a function, variable, or by hard-coding it.

      The following data types are supported for the fields:

      Table 1. Supported data types for the fields
      Type Description
      Text String value.
      Boolean Selection box. Selection indicates true value and unselection indicates false value.
      Number Numerical value.
      Date Date value in yyyy-mm-dd format. You can also use the GlideDate object.
      Choice List of valid choices defined in the Dynamic Data Schema field.
      Reference Valid GlideRecord.
      Radio group Groups that contains a different set of fields. These groups are available as a choice in a drop-down list when you edit a connection. The fields in each group appear when you select the required group from the drop-down list.
      For example, consider the following structure of radio group defined in the Dynamic Data Schema field:
                   {
      		"name": "radio_groups",
      		"label": "Radio Groups",
      		"type": "radio",
      		"groups": [{
      			"name": "radio_group1",
      			"label": "Radio Group 1",
      			"fields": [{
      				"name": "radio_field1",
      				"label": "Radio Field 1",
      				"type": "text",
      				"defaultValue": "efgh",
      				"mandatory": true
      			}]
      		}, {
      			"name": "radio_group2",
      			"label": "Radio Group 2",
      			"fields": [{
      				"name": "radio_field2",
      				"label": "Radio Field 2",
      				"type": "text",
      				"defaultValue": "abcd",
      				"mandatory": true
      			}],
      			"default_group": true
      		}

      For this example, you can use the following code snippet to understand how radio groups are used in the script by using dot-walking:

                  {
                  	name: "radio_field.first_radio_group.radio_field1",
                  	value: "radio field 1"
                  }, {
                  	name: "radio_field.second_radio_group.radio_field2",
                  	value: "radio field 2"
                  }, {
                  	name: “radio_groups”,
                  	value: gr.getValue(‘radio_groups’)
                  }

      For more information on how to use dot-walking, see Dot-walking.

      Tip:
      If the pre-populated values are not appearing in the fields while editing a connection, navigate to System Diagnostics > Session Debug > Debug Log to diagnose the issue.
    9. Optional: In the Test Action field, enter the name of the test action.
      Creating a test action enables you to test a connection directly from an integration action in the flow view of Workflow Studio. The test action uses an action definition to test the alias that the template is currently attached to. For details, see Create a test action to test a connection alias from a configuration template.
    10. Add the template to a Connection & Credential alias.
      1. Navigate to IntegrationHub > Connections & Credentials > Connection & Credential Aliases.
      2. Open the alias record for the spoke.
      3. In the Configuration Template field, click the Lookup icon.
      4. Select the template that you created from the list.
      5. Click Update.

    Result

    When the user navigates to the associated Connection & Credential alias and selects Create New Connection & Credential, a dialog appears to collect their input. If you created a template for the OAuth Authorization Code grant type, you can also retrieve an OAuth token from this dialog.

    What to do next

    Test the template by navigating to the associated Connection & Credential alias and selecting Create New Connection & Credential. Verify that the dialog collects the expected data and creates the required records in the system.