Config slots

The source workflows of your Solutions contain variables (e.g. Slack channel, Trello board ID) which might need to be set by the End User of your solution.

You set these as 'project config' when building your workflows:

When a project is converted into a Solution, each piece of project config will automatically be given a 'config slot' and an entry in the Config Wizard alongside the corresponding connector:

You can then use each slot's External ID to query and update auth and config data via the Embedded APIs

When using the Get Solution Instance query we can see that the auth and config details are found within authValues and configValues:

1
{
2
  "node": {
3
    "id": "97fa58fe-0d67-423b-817a-e73d21887371",
4
    "name": "Bolo Zenden Typeform > Sheets instance 1",
5
    "enabled": true,
6
    "owner": "334b5717-e400-4c24-ac47-2d860a16d19d",
7
    "created": "2023-07-20T10:38:37.757272Z",
8
    "solution": {
9
      "id": "3569fd71-70e8-4b78-84cf-c14c44f216eb",
10
      "title": "Quickstart Typeform > Sheets",
11
      "description": ""
12
    },
13
    "workflows": {
14
      "edges": [
15
        {
16
          "node": {
17
            "triggerUrl": "https://936acb30-7958-4c51-8190-05f678265258.trayapp.io",
18
            "id": "a7becc8b-549b-43a2-9016-e7d69fcf4c5b"
19
          }
20
        }
21
      ]
22
    },
23
    "authValues": [
24
      {
25
        "externalId": "external_typeform_authentication",
26
        "authId": "f257e1c7-0e0d-490d-9fe4-ed4f3abe3123"
27
      },
28
      {
29
        "externalId": "external_google_sheets_authentication",
30
        "authId": "f7c90fe4-de65-4d79-88b1-c5f53002809f"
31
      }
32
    ],
33
    "configValues": [
34
      {
35
        "externalId": "external_spreadsheet_id",
36
        "value": "\"1miJOZQvaVdzrwF1wuUSouHVch43Z9FyRvS5WP9wm1PM\""
37
      },
38
      {
39
        "externalId": "external_form_id",
40
        "value": "Zx86yu9P"
41
      },
42
      {
43
        "externalId": "external_sheet_name",
44
        "value": "\"leads\""
45
      }
46
    ]
47
  }
48
}

Importing config data on behalf of users

Copy

It is possible to push data from your own application that does not need to be visible to the end user.

For example you could pass in a user's email address or other details which might have already been recorded in your external application.

To do this you must first set a Config Key as hidden, by dragging it into the 'Not visible to users' section seen in the screenshots above.

The External ID can then be passed as an argument when using the createSolutionInstance API.

In the example below note that the value field is a JSON string and the " characters must be escaped with a backslash.

Also note that this mutation requires passing the User Token as a bearer (obtained after creating a user and authorizing a user):

1
mutation {
2
 createSolutionInstance(input: {
3
   solutionId: "0dc02586-xxxx-xxx-xxxx-cb98734578ef",
4
   instanceName: "some instance name",
5
   configValues: [{ externalId: "external_user-email-1" , value: "\\"me@example.com\\"" }]
6
 }) {
7
  solutionInstance {
8
   id
9
  }
10
 }
11
}

Note that the externalId of configValues is case sensitive.

For example if the externalId ai 'external_user-email-1' and you then create the Solution Instance with 'external_User-Email-1' then the mutation will fail.

Note also that the External ID must begin with 'external_'.

Shared config data (static slots)

Copy

For some integrations it may be that you want to set project config data to be the same value across all solution instances, without allowing the End User to set or change it.

In this you can use what we call 'Static Slots'.

In order to set project config data as static you need to:

1. Set the config data and give it a default value

2. In the solution editor, move the config data under 'Hide from users'. As a result, the 'Config default value' will be used for every end user and they won't see the option to see this.

If you need to update a static slot (e.g. creating a new authentication or changing the default value for config data), then you will need to change this in the source workflow and then publish a new solution release.

Using custom lists (static lists)

Copy

You may wish to present your End Users with an arbitrary field for which you want to hard-code a custom drop-down list of options they can choose from.

For example, you may wish to ask them what department they work in and present them with a list of departments.

In the Solution Editor you can check the 'Static List' option:

You will then be presented with the Static List window where you can enter the values which appear in the drop-down:

Note that a default value must be set.

Your End Users will then be able to select from the list in the Configuration Wizard:

Allowing users to input custom values

Copy

It is also possible to allow users to enter an arbitrary custom value in a drop-down list, instead of choosing from one of the options:

In the solution editor this is done by ticking the Allow custom values box:

Note that this is turned off by default as, with some service operations, it can cause errors by allowing users to enter invalid values.

So this feature should be thoroughly tested before going live.

Avoiding errors with config data

Copy

Conflict of default values

Copy

You will get an error message if two of your workflows have used config data with the same name but different default values

For example, if one workflow sets "email-name" as 'Support Team' and "email-address" as 'support@acme.com', while another workflow sets "email-name" as 'Sales Team' and "email-address" as 'sales@acme.com', you will receive the following error:

ERROR: Config keys email-name,email-address are used in more than one workflow

Re-using config in multiple connectors

Copy

If you are using the same project config in more than one service connector you will need to slightly alter the way you enter the config in the connector operations.

The first service connector to use the config can do so in the normal fashion - using a standard $.config.xxxx jsonpath.

Before using the config in any other connectors, you will then need to use the Text Helpers connector to set the config data type.

Then any second, third etc. service connectors that wish to use the same config can use the result of the Text Helpers step.

For example if you wish to use config in both a Trello 'Create new Board' step and a Slack 'Create Channel' step, the Trello step would look like this:

Then use the Text Helpers connector to set the data type for any subsequent steps:

Then, for the Slack connector, use the result of the Text Helpers step:

This will help avoid the 'Config slot cannot be used for more than one user authentication' error:

Note that you will also need to do this for steps that use the same config with the same connector but different operations:

This will help prevent the 'config slot cannot be used in more than one ddl property' error: