What does “Tab” mean here? Is Completions just a table?
Completions are available here:
Completions aren’t dissimilar to Tables, but they are a little less flexible. For example, Completion data can’t be reloaded and edited like table data. Additionally, completion data from one app can’t be used for another.
For standalone apps to do basic data collection completions are slick, because they save having to build a table, add a placeholder, create a record, and write fields. It will just automatically record the value of each variable when the app is completed. I don’t use completions often because of the aforementioned limitations, but many customers use them almost exclusivly.
That makes complete sense, but I still have the question: can I ACCESS this data somehow through the API? (From docs it doesn’t seem so).
You’re right, this data can’t be accessed through the API. A little more context around this limitations:
- Historical context - Completions predate tables significantly, they were the only way to store data in Tulip apps until mid 2019. This had all the limitations I listed above. Tables, and the eventually the API came long after completions.
- So why do completions still exist? Beyond the simplicity they provide for a simple application, completions are also critical in highly regulated industries where data immunitibility is absolutely critical.
I see no reason we couldn’t make this data accessible through the API, but editing or adding records over the API is more than likely something we wouldn’t consider. I will connect with the engineering teams to understand what the underlying limitation is here.
Just ran into the very same problem… any update on this? The immutable nature is exactly the point of interest…
Is there any update regarding access to the completion data? Without this access, I’m having to re-save the fields, which is redundant with the data that the completions automatically save.
I think most of the cases I am encountering customers aren’t fully using completions, or they are replicating what completions do in parallel in their own tables. That’s kind of a weird situation but it gives them the flexibility to use the pseudo-completion data with a little more flexibility. It also lets them get their own completion information out of the system.
You can’t entirely live without completions. For example, there’s an action under App that lets you redirect to another App but it’s “Complete App Then Change To.” You can’t change apps without completing, and you can’t initiate a change app from any other trigger or control.
Complex customers generally have a lot of apps and app groups. The technique described here shows a way to handle routing but it might be nice to detach app redirection from completion.
I personally would like to also see “Go to app without completing” and I would like to see that “go to app” be available in any trigger I want.
One thing about Completions that I wonder is if you implement some interface to get at the completion record, can you just make it look like a table (even if it really isn’t) so that it uses the table api rather than adding a whole new one?
This probably isn’t a high use case but it would be useful to me. For the time being, I’m going to keep advising people to more or less replicate the completion data they need in their own tables.
This would be a useful feature to be able to access completion through an API to do analysis. Otherwise I would need to build app logic to add the same data to a table. So not impossible but adds lots of complexity to apps + we already have a lot of tables to manage.
Also would be helpful to do through API because when I try to pull 2-3 months of completion data, it crashes our instance haha