Connecting Board uses a deleted pulse id

I am updating data from the api and started to notice that some of the connecting_board values where were not populating.

Cause: When the api event fired an update_column_value for a connecing_board column. It send the values from the board_id (connected board) and linked_ids (records). However, the event is sending linked_ids that have been deleted and recreated.

I traced this back using the activity logs within graphQL.

How do I get the events to start sending the correct pulse_ids from a connected board?


Hi @jkin

It is not only through the API, a mirror column still shows data if a deleted (mirrored) item. See also: Mirrored Items pulling through deleted items - #9 by codyfrisch

Thank you @basdebruin. That is very helpful to know.

Tips to help this a bit:

Assumptions: Items on Board A link to a single item on Board B using a connect-board column set up for a two-way connection. Board B may link to many items on Board A using this one column.

  • Configure Board A’s connect-board column (with Board B) to allow only one item
  • Configure Board B’s connect-board column (with Board A) to allow multiple items.
  • If using an account with column permissions, prevent editing of the connect-board column on board B by all but owners. (see below for why)
  • Create a webhook for “When item is deleted” on Board A (this existed on the enterprise account i was recently part of - it was new). Set up your application/integromat/ scenario to set the connect-board column on the now deleted item to “null”.
  • Always create the connections from Board A to Board B, and remove them the same way.

There is another issue that if you create a connection from Board B to Board A - the value of Board A is stored differently and you cannot simply set the column to null to have the connection vanish from board B. The connection has to be set on Board A to be able to null the column and have it then remove from Board B. Dumb.

The end result is setting the connect-board column on Board A to null on delete will cause that item to be removed from the list of connected items on Board B.

This shouldnt be required and I have discussed this with an enterprise customer success manager for my previous organization that deleted and archived items should filtered out from the connect-board column and hence mirror columns (this should be a column setting - maybe someone wants them for some use case), and API calls should not return them unless an “include deleted/archived” parameter is set on the query.

hi @codyfrisch

Correct, the delete_item webhook was announced recently, I believe also for Pro accounts. That would help but I agree with you that this complex workaround should not be necessary at all.

Yeah and without the delete_item webhook, my process was using another webhook. But now days, there is an easier workaround to that with a custom recipe

Trigger event (status change, button press) then
Clear column
delete item.

While it doesnt use the direct delete feature - it at least lets it be done without going to custom code. Still requires training people to use a Delete button instead of delete function.

If we had an “Item Deleted” trigger for custom automations that would make it easier.

Easiest though would be if they just fixed the issue. Deleted items shouldnt show up in connected boards or be mirrored. Plain and simple.

We just release our first version of Rollup Multiple Boards that is using the item_deleted and item_archived triggers. Works wonderful.