While this is not currently on our roadmap so I can’t give a timeline I can say that I would really like to have this capability and you’re right there’s no reason not to. This is not a great solution, but aside from using an outside service you can also hover over a a record in your Database and see the record ID by looking at the end of the URL in the bottom left of your browser window.
3 Likes
Unfortunately that doesn’t help when we need to get records dynamically/programmatically… But of more concern is that this isn’t even on the roadmap???
1 Like
Well I think so I just don’t have a timeline for when it will be added at the moment.
2 Likes
so true ! I need to update my last collection record remotely, and i’m just no able to do it easily, i have to send the collection count via API first and by deduction ask for the last value. The same API call number but much more elegant. futhermore, if i delete a record i will be on trouble. It’s definitively mandatory.
1 Like
This is insane we still don’t have this. Adalo seems to be focused on people launching apps more than scaling apps…
1 Like
There are some features’ requests on adalo.canny.io, feel free to upvote:
Best regards, Victor.
2 Likes
Hi @Victor,
Thank you for the work around and debug, This seems to work really well until it is resolved. I have a question regarding the query parameter though. Using this method, how would you use the query parameter to GET specific data?
Hi @Shnate,
Sorry, I’m not sure I get your question. What exactly would you like to achieve?
Best,
Victor.
Hi @Victor ,
No problem. I would like to know how you would use the query parameter filter on a list of an Adalo external collection that was made from a normal Adalo database collection. Hope that makes more sense.
Hi @Shnate,
It’s not possible to get specific data using any query parameters - Adalo Collections API is quite limited. There are no filters & etc. (like what you have in Airtable).
You can:
- get one record (using record ID)
- set offset for GET request
- set limit of records returned for GET request.
Just in case, you can find short help doc about API here: Collections - Adalo Resources.
Hope this helps.
Best regards, Victor.
Yeah well that has quite some downsides:
- It only runs every 15min, so what happens after the user creates the account until FINALLY that Scenario runs? Pretty bad user onboarding experience if the user has to wait 15min before the app actually works properly.
- You will notice that the “Watch Records” Module will always go through ALL RECORDS which changed since you created it. Meaning, the more records in your Adalo DB you have the more records Integromat/Make will have to run through which will not only cost you a ton on Make but also make your Adalo app slow.
Or did you find remedies to the above I am not familiar with? Would love to know.
With 
Michael
Just thought to post this component made by Pragmaflow that may help you guys 
: A Button that gives the Record Id
Hi,
Filtering will never be possible in a sustainable way until Adalo enables filtering itself. As you just referred to what MAKE does, whenever you apply a filter, Adalo would need to go every single request, and don’t forget that the API returns 100 results per page which will again be another slow process on top, if you would want to filter through an HTTP request and not “Watch Records”.
You could solve though the issue of “Watch Records” by using hooks instead, to not go over all the results and of course using a paid plan in MAKE to increase execution speed, but still, you are limited to 1 min executions.
The limitations of MAKE and Adalo in general, is something discussed already here for quite some time, hopefully ADALO will work on the API soon, as it is now, it is pretty standard and not very usable, only to use in very specific cases.
100% agree.
Adalo has great potential but it’s not quite there yet for a real app that does not give you massive headache or limits you too much.
Still, amazing concepts in there. Just need some more execution of community requested features as we know what we need 
I guess.
1 Like
This thread started long time ago
Though fundamental problem still exist: Adalo doesn’t allow to access record internal ID from its interface for some reason. This question was raised on the forum multiple times, there are at least 2 feature requests for it: (Make unique record IDs publicly available | Voters | Adalo, Expose Record ID for Filters/Visibility | Voters | Adalo), but no improvements so far.
So, as of now, there are following approaches to get record ID I’m aware of:
- For Make/Integromat scenarios. It’s better not to use Watch Records due to the delay and excessive credits consumption. What I usually do is:
- add an additional field to the collection, call it UniqueID
- upon creation of a new record, generate UniqueID using RAND with looooong numbers / current time
- (these steps aren’t required for Users collection - email is already unique)
- when launching the scenario via Custom Action, I pass this UniqueID to the webhook in Integromat
- in Integromat I do: Webhook → List Records → then filter by UniqueID is equal to UniqueID in a webhook
- resulting record will be the one needed.
This is very, very resource-consuming (list records could run for a long time), but it works.
-
As @dilon_perera mentioned, there is a Pragmaflow’s component - a button which helps to get access to record ID. Could be pretty useful sometimes.
-
Another workaround is to create a new record in a collection using Adalo API. As a reply, POST should return JSON with the newly created record data; you can get id from there and store it in a “mirror” field you’ve created (another custom action with PUT action).
The downside here is that Adalo API isn’t stable, and you can’t use this newly created record as Current record in the subsequent screens.
Best regards, Victor.
All of this breaks down once you hit 5,000 users in your database.
The database is aws and the support team doesnt understand (or is to cheap to change) how to increase the memory allowed for the database queries.
So I was previously using Zapier (expensive, but more reliable so I was willing to pay) to create a second accessible ID column in my user database. Once I imported my users, you can no longer access via 3rd party service like Zapier to watch for records.
And as you mentioned, the API is not reliable. I was only getting ONE out of every FOUR users to have their information imported properly using the API ‘custom action’ within a signup form.
This caused absolute havoc.
It’s not reliable.
And then it doesnt scale.
The ‘bubble gum patch’ method of simply connecting and accessing database records at this point is a joke.
The best solution I have found is creating a universal variable via API and having a two part update.
In my case, when a user is created, they pull in the Universal Variable which is named ‘Max ID’ but there is only one variable.
That variable is the current maximum variable (recordID) in the database.
Then that variable is +1 in the form that is being filled out by a new user, their information is sent (user is created) (at the same time, that maxID+1 is told to update the universal variable but it’s still unreliable) and on the next page (to reduce load on one action/page), the entire user database is queried on that self-created RecordID and looks for ‘maximum’ number in that column to update the universal variable to make sure the maxID is actually correct.
That variable that is queried on the second page is then used to update the universal variable.
There is a chance, as people join, that two people get the same variable.
But it’s rare that you would have this happen a lot.
Unfortunately, even setting it up like this and with a slow trickle of users being created, it still fails to set that +1 variable on the user sometimes and sometimes it fails to query the maximum ID in a column. I would say about one every 10 queries gives someone the same number and fails to count +1 on the variable. That comes down to the unreliable API, so unreliable that you can call it twice in two different ways and still it wont work.
I’m watching it like a hawk, I’m having to adjust it multiple times a day.
And I’ve doubled or tripled the actions I have to use because Adalo’s queries are slow and not reliable.
When I attempted to short cut the entire thing and add a user via API entirely, again it was unreliable, and I ran into other issues like it would suddenly accept non-email fields in the email field, etc. The data wasn’t properly checked. It wasn’t worth the extra headache with it being cheaper on actions, but less reliable on executing AND handling the data properly.
For #1 - for me it usually stops working at around 7-8K records. But this depend on the collection size: for collections with large records it this “instability limit” is lower. I guess API backend server has some kind of milliseconds or memory limit for a query execution.
You can use pagination - but this is not the most exciting thing to do in Integromat.
Also I am not sure how methods ##2,3 will break depending on the records quantity. I didn’t play a lot with Pragmaflow’s component, so can’t say for that; but for records creation via API - it does not depend on the record amount in the DB. This is a POST request which does not imply any time-consuming GET ALL requests (which usually break).
As for using MAX (or COUNT) - I would advice against it. In my experience these capabilities were breaking too frequently.
Also, using the MAX approach has a serious flaw in logic. Imagine we have 10 records, internal IDs are mirrored successfully and the next one is added. Let’s say the 11th record is added, we get MAX from mirrored = 10, and set new MAX to 11. Internal ID is 11 as well.
Then we delete the last record added.
After this, when adding a new record, MAX will return 10 (and new MAX will be 11). BUT the internal ID will be 12, as they are auto-increasing.
I’m not even discussing using COUNT as after deleting any record it will be out of sync.
No ideal solution here. All is duct-taped; so for anything larger than 5…7K records it’s better to host data elsewhere. I’m facing this every day in a lot of cases - to say that I’m unhappy is to say nothing.
Victor
I was very clear about using ‘maximum’ in count and not the actual count for variables on my secondary backup-insurance (on the loading of a second page, where no major actions take place).
I also described using a universal variable set as MaxID, using this as the primary and using Maximum on the user database as the backup.
So far, my universal variables are the work horse.
But adalo doesnt have built in universal variables. I had to ductape that together.
And the entire process means instead of simply being able to access the RecordID, I have to use 3, 4, 5 actions to just get a user’s id when they are created.
Absurdity.
1 Like