I am developing an inventory application. In it I came across a requirement to allot part of the material required to be procured and part to be fulfilled from our stock. To lessen the steps that the end user will have to take selecting the item twice, once for each transaction I intended to reload the previously inserted item upon submittal of the record. Because my selection fields are cascading dropdowns I can't setup an On Load value to it. Other than that I think it will be a good idea cuz it will allow us to setup default values to the cascading dropdowns as well.

Datapages cannot currently be opened directly into Grid Edit mode even if the "Grid Edit" flag is set on the datapage settings. Instead the datapage opens in a list view and items such as checkboxes appear as values yes/no instead of a checkbox.
The datapage is therefore unusable until manually switched to grid edit.

The datapage can be forced to switch to Grid Edit via javascript but the page still loads in list mode and then refreshes when the script is executed which is a terrible user experience and makes the app look very unprofessional.

The "grid edit" (or another setting) should allow for the form to open directly into grid edit mode.

This is basic and standard UI functionality so very surprised that it is missing or that the "grid edit" flag bug has not yet been fixed.

Caspio can only handle a "one-to-one" or a "one-to-many" relationship in a table field. As a result, creating a "many-to-many" relationship requires creating a third table.

Competing database programs (even those that are less developed than Caspio) allow a table field to easily hold references to multiple other entries in another table -- i.e. a native many-to-many field. (Webflow, Knack, Bubble are other ones I've looked at, and they all had it).

Increasingly, the world works in a "many-to-many" way. For example...
- A blog post will have many categories
- An article may have multiple authors
- An event may have multiple locations
- An individual may work for multiple employers

If someone wanted to create these many-to-many relationships in Caspio, they currently have two options.

Option 1: create a third table that sits in the middle of the two tables that need to have a many-to-many relationship. Limitations are:
- Cumbersome and complex to set up and manage
- Creating the many-to-many relationships during data entry requires establishing a separate entry form away from the main table entry form (since an entry form only applies to one table). This slows and complicates the data entry process.
- Searching functionality on the many-to-many table requires workarounds. Let's say you have a search datapage for a table. That search datapage cannot refer to the many-to-many table since it will produce duplicates of results. So, you have to build multiple search pages.
- To display the many-to-many relationship in a list or details datapage, you have to insert it as a iframe list datapage within the embedded list/details datapage. The iframe html formatting is very hard to get to match to the Caspio datapage formatting, so you need to therefore build the entire details page using html blocks.

- If you have a dataset that needs multiple types of many-to-many relationships, the problems above compound in a very significant way.

Option 2: use Caspio's List datatype. This datatype has some elements of a many-to-many relationship, and has been a lifesaver as otherwise I couldn't have gotten a basic version of my application to work. However it's an incomplete buildout, which Caspio itself noted in the release information 2 years ago. The limitations are:
- There is no way to bulk replace or update the list fields in the table. The "search and replace" function does not work on this field. Nor do Tasks. So if you have a database with thousands of entries, and need to change a blog tag for example, you need to either:
a) Go into each entry individually and change it; or b) Convert the datatype into text, do the search and replace, and then convert it back to list. This however is very tricky. When you convert the datatype it deletes any datapage reference, so all those need to be rebuilt. (I suppose you could duplicate the table, convert the list field to text, search and replace, convert back, then trade out the tables and hope nothing got screwed up.) Also, you can't use a comma in the list field, because that's what Caspio uses to recognize the separate elements of the list field. If you have a category called "Cats, Dogs, and Mice" when you convert it to text and back to list, you now have three separate categories: "Cats" "Dogs" "and Mice". Additionally, the search and replace functionality is very tricky, even with text, since it will replace fragments of words within entries. For example if you have "Big Green Building" and "Green Building" as two categories, and you do a global search and replace of "Green Building" only, it will impact both "Big Green Building" and "Green Building" even though you only want it to apply to the latter.
- The list datatype can't be used in "Tasks" so you can't build a task to do something. For example, if in all the blogs with a tag of "Cats" you also later decide to have it also say "Animals"... again you have to go into each entry and manually add it.
- In a search and report datapage, it forces you to list all of the list category options in the dropdown or listbox field -- you can't go in and set custom search options if you only want to show a selection of the categories, or order them a certain way. Again this is an issue in case you don't want to show every single option in the list field, in case you are developing some. To get around this you need to separate the search and report datapages using parameters (where the first is a submission form with virtual fields, and the second a report datapage that catches the search entries via parameters). This gets around it but then opens up another list of limitations and headaches.