“List All Members” module Answered
This is a kind of niche question, but one for the Make users out there (John Matias ?)
I am creating a scenario that checks that Airtable and MailerLite correctly reflects membership statuses in Memberstack, as I’ve noticed that in several cases subscription updates or reactivations haven’t updated correctly.
With MS 1.0 there was a “List All Members” module. This exists in MS 2.0 but is limited to 100 members. I have 2K, so this doesn’t work.
This scenario in the screenshot works, but ends up consuming a huge amount of operations (8K!).
Does anyone have an idea about how I can do this in a less intensive way?
What I want to achieve is:
- Check that the “plan ID” and “Plan Name” are the same in Memberstack/Airtable/MailerLite, and update Airtable/MailerLite if they are incorrect.
Comments
6 comments
Maybe a question out of ignorance to your situation, but why would it be needed to check?
If it gets it right once, shouldn't it be fine moving forward?
If you can help me understand the reasoning, I may be able to figure out another way to get the same goal done.
I moved to 2.0 in Jan, but have still found that there are some edge cases where the automations don’t fire correctly and update Airtable/MailerLite when MS updates. I have been fixing these when they arise, but haven’t caught them all. I want to have a create a scenario that fires periodically (weekly?) to fix any of these discrepancies.
Which automations aren't firing? Would be great to see those and fix the problem before it arises
They are edge cases that I only find (and fix) when they happen.
The point is, I can’t anticipate them all and would like to have a way to check the data is updated on a regular basis.
Hey Alastair Budge thanks for pinging me on this, I'm flattered you thought of me! ha!
I've been able to avoid this list members issue for a while and haven't had a use case for it, thankfully. But the question's come up several times so I thought I'd try to figure out how to 'paginate' or cycle through all of the members using one scenario in make.
I think I've got a working solution but boy was it a brain twister! I'll share an image of how I set it up and I'm happy to try to provide clarity if you want to implement it. But honestly, I don't think this would save on the number of operations at all.
All this really does is list all of the members in the account in batches of 100 for however many times needed.
Here's the scenario:
The initial HTTP request only fetches one member but it does the trick of actually getting the total count of members in the account. Then I dived that number by 100 to get the total number of times to set for a repeater module. The first leg of the scenario grabs the first batch and then sets a variable for the member ID. The second leg grabs the very last member ID which you then can feed into the module so you can get the next 100 members "after" that one. It sets the member ID variable again so that when the repeater starts it gets that last member ID which then lets you get the next 100 members. In my test I set it up so that it would only run four times thus getting a total of 400 members in batches of 100.
I have no idea if this is helpful but if nothing, maybe it can spark some inspiration?!
Ahha, amazing, thanks so much John Matias. will check it out and let you know if I have any q’s!
Please sign in to leave a comment.