New trigger type ID take All by default

Custom Apps
,
1

Hello,

We’re creating a new trigger (polling) for our custom app. Our trigger gets an array of items like this one:

{
  "id": "24",
  "name": "Richard",
  "email": "richard@example.com",
  "creation_date": "2024-01-19 15:13:20",
  "active": "1",
  "source": "When sending a test",
  "confirmed": "1",
  "confirmation_date": "2024-01-22 16:07:50",
  "confirmation_ip": "127.0.0.1",
  "tracking": "1",
  "language": "en-US",
  "last_sent_date": "2024-01-22 16:07:56",
  "last_open_date": "2024-01-22 16:07:56",
  "last_click_date": "2024-01-22 16:07:56",
  "status": "0",
  "subscription_date": "2024-01-22 16:07:56",
  "unsubscribe_date": "2024-01-23 17:07:56"
}

For the trigger type, we tried “id” like this:

"trigger": {
    "type": "id",              // Identifies trigger polling by date.
    "id": "{{item.id}}",       // Identifies items by its property: "id".
    "order": "unordered"       // Specifies in what order the remote API returns items.
}

This works well, but it only takes the users with an ID > the ones that have already been handled. Since the route only returns the relevant users, we would like the trigger to take ALL results into account.

Is it possible? If so, what do we need to add to the trigger and where (communication, epoch, etc)?

We noticed that when right-clicking the module in a scenario we can choose where to start and select “All”, but that only applies to the first execution, the next ones revert to the behaviour I first described.

Alternatively, we tried to make the trigger into a “date” type like this since the unsubscribe_date will only “go up” each time the trigger is executed:

"trigger": {
    "type": "date",              // Identifies trigger polling by date.
    "id": "{{item.id}}",       // Identifies items by its property: "id".
    "date": "{{parseDate(item.unsubscribe_date, 'yyyy-MM-dd HH:mm:ss')}}",
    "order": "unordered"       // Specifies in what order the remote API returns items.
}

We however couldn’t actually manage to make it work by following the documentation.

Thank you for anyone having some clue as to how to do this :slightly_smiling_face:

2

You are missing the Iterate directive.

For more information, see Trigger (polling) - Make Apps

2 Likes
3

I do have the “iterate” part, I only showed the “trigger” part to explain how I configured the trigger type :slightly_smiling_face:

Here is the complete communication configuration we came up with:

{
	// Request to API endpoint
	"url": "/index.php?page=acymailing_front&option=com_acym&ctrl=api&task=getUnsubscribedUsersFromLists&connector=1",  // Relative to base URL
	"method": "GET",
	"headers": {},                       // Additinal HTTP headers
	"qs": {
		"listIds[]": "{{parameters.listIds}}" 
	},

	// Response handling
	"response": {
		// Splits the array from API response into bundles.
		// See documentation at: https://docs.integromat.com/apps/app-blocks/api/pagination
		"iterate": {
			"container": "{{body}}",
			"condition": false
		},

		// New items search specification
		// See documentation at: https://docs.integromat.com/apps/app-structure/modules/trigger#response.trigger
		"trigger": {
			"type": "id",              // Identifies trigger polling by date.
			"id": "{{item.id}}",       // Identifies items by its property: "id".
			//"date": "{{parseDate(item.unsubscribe_date, 'yyyy-MM-dd HH:mm:ss')}}",       // Identifies items by its property: "id".
			"order": "unordered"       // Specifies in what order the remote API returns items.
		},

		"output": "{{item}}",            // Outputs whole each iterated "item" object as separate bundle.
		"limit": 300  // Limits number of output bundles as requested by user (even if API returns more items).
	}
}
1 Like
4

Hmm I’m not sure if it’s because the ID is a string, not a uinteger. Usually IDs are numbers and do not have the quotes around it.

"24"

What happens if you try this

"id": "{{parseNumber(item.id)}}",
1 Like
5

Thank you for your reply, I tested the parseNumber on the id value but I have the same result.

Note that the first call correctly gets the results, so make.com seems to correctly recognise the user IDs when getting the response.

I modified the route called to always return a user, to be able to test easier. Here is what I get when testing the trigger:

6

Hello Jean-Baptiste,

The thing is that Make needs a field (ID or date) that will help sort the results.

With the “id” type, for example, the user 2 will always show up after user 1. Because Make will sort the items sequentially based on this id.

The main question is: what exactly do you want to watch?

Because using the “id” type with user id is fine if you want to watch new users, but it will not work if you want to watch new unsubscriptions, for example. In the latter case, using the “date” type with the “unsubscribe_date” is indeed what you need.

To help figure out how to set up your trigger module, I would recommend checking our course on custom apps, where we have a video specifically about trigger modules.

image
image934×302 18 KB

2 Likes
7

Thank you for the link!

We have been able to make it work with the trigger type date :+1:

The issue was that, at some point, we set the unsubscribe date of a test user to February 2024. So records would be excluded by make.com even if we just unsubscribed some test users.

To avoid this kind of confusion for other developers in the future it would be nice to have the “Last ID” / “Last date” clearly visible on a scenario, maybe with a tooltip explaining that make.com will automatically exclude results with a lower ID / earlier date.

Thank you for the help :slightly_smiling_face:

2 Likes