How to safely update Memberstack members in Make.com without cascading webhook triggers or infinite loops across scenarios? Answered

• 

  Raquel Lopez

  • April 30, 2024 13:33

  Depends on how you're constructing the logic of the program.

  If you use different urls as custom Webhooks in Make to send data to, yes, you are able to filter Webhooks, and create one scenario per custom webhook.

  But if you use MS webhooks as a trigger, then you won't be able to filter because you are using their available events as your entry point.

  So in summary, MS won't trigger because you said so, it triggers because a changed happened in their data base, it doesn't matter what did. If you wanna know what did it you'll probably have to add like a proxy before the update happens... it would not be a standard like solution 😅

  Or you can use filters in Make to check what changed, you might be able to create a custom solution that works for you using custom fields 🙂

  0
• 

  Josef Eines

  • April 30, 2024 13:33

  Thanks Raquel! 🙂

  0
• 

  Bill Utaegbulam

  • December 09, 2025 16:20

  Hello. I have a couple Make.com scenarios revolving around Update Members and Watch Updated Members that are burning through operations/credits unnecessarily. Essentially I have one scenario (Scenario 1) to watch New Members, which ends in an update to a custom field using the Update Members module (the typical CMS ID trick for Webflow stacks). That field, plus a metadata addition are the only things I need to update in that moment. The problem is that it's triggering a Watch Updated Members trigger in another scenario (Scenario 2) every time, and I don't need it to run. Moreover, I used to have an Update Members module at the end of Scenario 2, but that was causing an endless loop until it rate limited.

  I'm aware of a couple fixes I could go for, such as these below. At this point I'm just curious if I'm missing something with my setup. The "problem" actually makes sense in terms of why it happens, but I feel like this wasn't an issue in the past while using a very similar structure of updating a member as the end of a workflow, but maybe I'm just now noticing it with Make's new pricing model. I can share my blueprints if that helps.

  https://memberstack.slack.com/archives/C033F0SLTLK/p1755432963873609?thread_ts=1755347521.725129&cid=C033F0SLTLK

  0
• 

  A J

  • December 09, 2025 16:21

  Hey Bill Utaegbulam,

  With the use-case you shared, I believe it's not a problem with your setup, the workflow does seem like connected unintentionally due to the modules setup in each workflow.

  You can double-check if the triggers you have setup for both the workflows are the apt ones based on your use-case or does some other trigger make sense etc.

  But, if you are sure the workflow is setup as per the logic requirements, our best bet is to make sure we filter things out via some workaround like filling a field to notify what the update is about and resetting it along the way to minimize the operations.

  0
• 

  Bill Utaegbulam

  • December 09, 2025 16:23

  Thanks for the quick followup again AJ. Yea this one is weird, and I do feel the current split across two scenarios is necessary for this particular app's signup flow.

  So I'll probably roll with the hidden field/filter setup that you detailed for someone else previously.👍

  0
• 

  A J

  • December 09, 2025 16:24

  Welcome 😇

  Let me know if you face any blockers with the setup.

  0
• 

  Bill Utaegbulam

  • December 09, 2025 16:24

  Hi A J. I've pretty much got this working with a "last-update-type" field and some refactoring in Webflow. One piece I adjusted was replacing the built-in Memberstack profile image uploader for a custom solution that writes an image to the Webflow CMS items for user profiles. I did this because I couldn't figure a clear way to simultaneously change a custom field with the automatic uploader.

  The cherry on top for would be to pull this profile image back into the Memberstack dashboard. I don't believe an API call can be made to change profileImage on the member object, and data-ms-action will bring up the uploader which I don't need anymore, so I'm a bit stumped.

  0
• 

  A J

  • December 09, 2025 16:27

  Hey Bill Utaegbulam,

  You could probably setup a script to fill the custom field when user uploads a profile picture via the Memberstack's profile image uploader.

  <script>
    document.addEventListener("DOMContentLoaded", function() {
      let memberData = JSON.parse(localStorage.getItem('_ms-mem') || '{}');
      if (!memberData?.id) return;
      const memberstack = window.$memberstackDom;
      const profileImageElement = document.querySelector('img[data-ms-member="profile-image"]');
      if (profileImageElement) { 
        profileImageElement.addEventListener('load', async () => {
          const currentProfileImage = profileImageElement.src;
          if (memberData.profileImage !== currentProfileImage) {
            const setUpdateType = await memberstack.updateMember({
              customFields: {
                "REPLACE-WITH-CUSTOM-ID": "Profile Picture Updated"
              }
            });
            memberData = JSON.parse(localStorage.getItem('_ms-mem') || '{}');
          }
        });
      }
    });
  </script>
  

  Now few things to note here would be to make sure to have the custom ID of the actual field that you want to update in memberstack in the place of REPLACE-WITH-CUSTOM-ID.

  In case, you have the profile uploader and the profile form in the same page and have the hidden input field setup in the form (i.e. the last-update-type) inside the profile form, then it would be best to have a separate field in Memberstack meant to listen to profile picture updates. For example, you could create a field in Memberstack named 'profile-pic-update'. You can have 'last-update-type' hidden field inside the profile update form and in the code above you have the newly created field's custom ID instead 'profile-pic-update'. And have the workflow via Make / Zapier where you are resetting the last-update-type field, also reset the value of the profile-pic-update in Memberstack simultaneously.

  This is to ensure that in-case a user updates a profile picture and quickly updates their first name, then using the same custom field to store the update type data might lead to some confusion due to overriding of the field.

  In case, the update type for profile picture update and profile form update is the same in your project use-case, then no need to add separate last type fields, the one you have will do.

  I tested this approach in a personal dummy site and the code updates the relevant field in Memberstack if I update a profile picture. Hope this helps.

  0

Please sign in to leave a comment.