Zapier Member Edit Trigger - What causes trigger?

[Zac A]

Hi,

I am having some trouble identifying why my zap is not triggering when a member is updated. Can anyone elaborate on what information Invision is classing as an edit?

Results have been inconsistent with editing members; I have tried the below with varying success and plenty of wait time between the changes to allow the system to check:

• Display name change
• Email change
• Primary or secondary group change
• Custom field change

The zap takes the edited member information and inserts the updated data in a Google Sheet which applies some logic then triggers another action which will update the member if something important in the sheet changes.
Zap works fine when testing, and occasionally will detect a change immediately then back-capture all previous edits. From what I can tell, sometimes this has caused issues where a member has changed groups twice; first from group A to group B, then back to group A. The zap seems to grab the member history from most recent to oldest, so the information that is written to the sheet for that member sits them in group B.

Very keen to use this function but I'd like to understand more about the integration or whether other users have experienced a similar problem.

Thank you!

[Daniel F]

There was a bug in the edit action which was fixed yesterday. The new version is rolled out slowly, so to avoid waiting, I would suggest to delete the zap and create a new one , which will ensure that you’ll use the newest version. 

[Zac A]

Hi Daniel,

Thank you for that information. The issue relating to the different fields being sent through to the zap was identified through my support ticket with Zapier. 

I have recreated my zap but the issue persists. The problem I still encounter is that when a member is updated, sometimes it seems that there is no action by Invision to trigger the webhook. I have made relatively consistent changes to members over the last few days, just one field here and there and those have not been sent through. I've just replicated this behaviour in testing.

Can you please explain how the webhook triggers? It previously appeared to be that when edits reached a threshold (some amount in a certain time frame) it caused it to trigger, where a few edits seemingly flew under the radar. In testing the zap, I can see recently edited members, but that is manually triggering a refresh of the data. The webhook does not appear to be calling out to Zapier for single edits; at least in my testing.

Regards,
Zac

[Zac A]

Hi Daniel,

A follow up to this; it also appears that any action on the member can trigger webhook. The description of the trigger implied to me that it would action when something changed on the member's account. The action on the member's side seems to consistently trigger the zap, however admin actions still have the same behaviour described in the above comment. When a member does something that triggers the zap, the system seems to go back and capture the changes that happened prior to that action.

From testing, the following actions can form part of the "Member Edited in Community" trigger:

• Logging in/last activity updating
• Creating or replying to a post
• Getting points
• Watching a post/topic/forum

I feel like there is room for a zap trigger that looks to see when a member's account information is updated; not every action that member takes. By this, I mean having the capacity to trigger a zap based on when a member edits their email address, a member's primary or secondary group changes, etc. rather than the entire activity of the account.
The problem with having it action every time a member does anything is that it is causing a significantly greater amount of actions than necessary when member edits are relatively infrequent, but member discussion is highly common.

Thank you,
Zac

[Daniel F]

The "Member Edited" trigger is fired when literally anything except when one of these values changes (         'last_visit','last_activity',  'profilesync_lastsync' )

So yea, your observation is correct. It is also fired when somebody replies because his "total posts" count, last post timestamp, and probably also his achievement points value changed.

We thought that people would use Zapier Conditions once they need more control over the data, that said, we may improve this in the future and include a few filters into the "Member Edited" trigger.

 

Also, something to keep in mind, is that the webhooks aren't fired immediately.

We have a webhook queue, which collects the data and which is then fired via a separate request ( https://zapier.com/engineering/webhook-design/ leaving this link here for people who are interested in this)
Since you're on a demo that has probably not really that many visitors, the queue is also not running as often as it would on a live board!

 

 

[Zac A]

Hi Daniel,

The Zapier filters are not particularly useful as I cannot select either the parent "changes" field, or any of its children to set a rule to only run when certain child fields are updated.

Much appreciated re: the info on the webhook queue. That does indeed help me to understand the odd behaviour we've seen.

Unfortunately for us, the ability to selectively update that sheet when certain core fields are updated is a key function lest we run up a significant bill with Zapier! I would be very interested to see that development come to fruition, so if there is a way I can either monitor/place an official development request, please let me know.

Thanks again for your help on this one, it is greatly appreciated!

[2002faq]

I am really hoping there will be options for which changes trigger the webhook, as it is triggered thousands of times in a day.  With Zapier, this becomes very expensive.  Make.com makes it a lot cheaper, but this can still be reduced as most changes are not useful to me. I use filters, but those still have to be after the first step and thus i am paying for thousands of tasks per day.

steve k.