Using input and output schema

Note: Before continuing to the instructions below, note that picking fields from drop-downs which come from the auto-generated connector schemas is in theory an easy and simple method. However, it will not always be possible to use the input and output schema of connectors, as sometimes they will not produce fields you are trying to get to which may be one or two layers deep into the schema (e.g. the name of an assignee for an Asana task may be found in $.steps.asana-1.data.assignee.name).

If this is the case you should hardcode your lists and extract the nested data.

The example from the previous pages on hardcoding and mapping nested data is a good illustration, in that the Output schema for the Stripe 'List Customers' operation only shows the top-level 'Data' field and cannot drill down into id, name, currency etc.:

A very simple (and unrealistic!) example of using input/output schema is setting up a mapping for a workflow whereby each time a new Slack channel is created a Dropbox folder is created with the name of the channel mapped to the name of the folder.

So here you could use the following setup for the Operation Input in Service 1:

And the following for the Operation Input in Service 2:

And the following default mapping:

In deciding whether to use an input or an output schema for a particular operation, it will depend on what data is returned by either schema, and whether it is usable.

In the example above we could have used the output schema for the Slack 'Create channel' operation but this only returns the 'Channel' as an object, and the name is nested within it.

So using the input schema was necessary.

If you need to create a more detailed mapping with some of the nested data from within the channel object, you would need to use the hardcoded example with nested values approach detailed in the Mapping Nested Data guide (making use of Object Helpers).