Jump to content

Zac A

Friends
  • Posts

    4
  • Joined

  • Last visited

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by Zac A

  1. 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!
  2. 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
  3. 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
  4. 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!
×
×
  • Create New...