Subitem mapping/field in a recipe

Hi great community,

My integration app needs to have input of an item AND its subitems.
The fields from the item and subitems would potentially mapped by the dynamic mapping feature to a payload that my action endpoint could consume.

Is this something that custom action + dynamic mapping support?

Hello there @eyalos,

What would the sentence of the recipe be like, what fields would it have and what do you need to pass in each one?

I was hoping to be able to say “take some action on the item and it’s subitems”. Then my custom action’s endpoint will be invoked with the item and accompanied a list of subitems.

What I was able to do so far, is provide mapping for a board item - for the user to pick his fields. But what if I would like to expand that with multiple subitems mapping?

If you know the item, can’t you simply just lookup the sub items in your app using graphql?

@dvdsmpsn that would be my fallback… That’s the second base, because that’s lacking the option of mapping my app’s fields to Monday’s fields, i.e. user won’t be able to configure their columns to mine.

Hope that’s make sense, not sure I used the correct terminology.

1 Like

Trying again, maybe I’ll be able to get fresh ideas here…
My problem is that I can’t get the user to specify what columns within their subitem to be mapped to my app fields: for example, if a board item has subitems with column name “Report date” - I would like a dynamic mapping to allow users to pick that column to something in my app model.
I guess that’s not a trivial requirement, and maybe hard to implement, as any item can have subitems of any structure. Maybe that’s the reason it’s not supported.

I would like to check another direction:
If I’ll break my automation to a 2-part automation, as follows:

  1. When a certain trigger happens on an item level, an action will fire up - for creating subitem which I’ll be “in control” of its columns (perhaps even force that subitem to be unchangeable)
  2. When a second trigger happens, that indicates the user finishes with filling their subitems, my final custom action will fire up - which will use the itemId to lookup its subitems, as @dvdsmpsn proposed.

I wonder if people were able to overcome such a gap of subitem fields mapping?

Any chance someone was dealing with mapping a specific subitem’s column within a custom action recipe?

e.g. If a user has subitem columns with ID text__123, I would like to get the correlated value of this (text__123) subitem cell.

I’m clueless…

Hello there @eyalos,

Can you please show what you want your recipe to look like? What should the user be able to select when configuring the recipe and what does the recipe do?

Hi @Matias.Monday,

Consider the current behavior of a column as an input field within a workflow block’s action:


That gives the user the ability to configure a specific column, which its value will be received when the custom action will be triggered.
I would like the same ability in the subitem level, meaning: the configured subitem’s column will be inputted when the action will be triggered.

It’s a simple mapping task: between a user’s board structure, to an action’s payload structure.

Hello again @eyalos,

You can achieve that by:

  1. Creating a new custom field (subitemcolumn)
  2. Making that field of type list coming from an endpoint
  3. Creating a dependency between that field and “boardId”
  4. Then you need to use a trigger that passes the board ID as an output field and your custom action with the custom field you created.
  5. Create the recipe and configure it. Save.
  6. When the user configures the recipe and clicks on your field (becuase the source of the custom field should be “recipe sentence”), your custom field endpoint will be called and you will get there the board ID. You can then use that board ID to get all the columns of the subitem board via API. Then you can show those column titles as the options you send back.

What do you think?

Cheers,
Matias

@Matias.Monday That’s exactly what I currently do, my main issue with that approach is the custom field endpoint is being called without any token or user identified → which is required in order to query/call API, as you suggested:

I have a workaround to use stored access token in that situation, but that feels awkward.

Hello again @eyalos,

I just tested this and in the headers of the request done to your custom field, you should get an “Authorization” header with a JWT that has a shortLivedToken you can use.

Are you getting this header?

Looking forward to hearing from you!

Cheers,
Matias