Difference between Use specific columns and Row ownership

[Keith_Chikumbirike]

Can someone kindly assist with explaining the difference between Use specific columns and Row ownership if there is any difference?

I’m seeking this clarity so that I can see if I need to restructure my app and if any of the 2 would be useful in achieving what I what to do.

My challenge is my app will need to accommodate hundreds or thousands of users. However, I want their data to be limited to a number of rows and also for that particular data in those rows to expire after sat 24-48 hrs

the idea is their entries will be used to make certain calculations then ideally exported to CSV or PDF.

Is this possible or is there a similarly effective alternative?

[ThinhDinh]

Row ownership: Users download rows that “belong” to their email only. This data can be released anytime by removing the row owner settings.

User-specific columns: Columns that house data that belong to a non signed-in device’s session and is wiped off when they close the app, OR belong to to a signed-in user but can never be shared in a normal way to other users, unless you use some set columns to write to a normal column.

@Keith_Chikumbirike

However, I want their data to be limited to a number of rows and also for that particular data in those rows to expire after sat 24-48 hrs

You don’t have a time-based trigger to make the data “expired” (like clearing them or putting them elsewhere). The data will only be available to the specific user anyway, what’s your use case for expiring them?

[Keith_Chikumbirike]

My thinking was that clearing up the rows will save a lot of space.

So far, before I have brought in many users, I discovered that the app seems to be overwhelmed by the data in the many rows.

If the rows aren’t deleted or cleared then data will surely accumulate yet the basic function of the app is to make lists of lists based on the selection of certain products items. So 1st a user makes a list of products to adding them to their relevant project, then the app make lists of the “ingredients” of those selected products. Which the user will view as an inline list.

The primary function of the app is to list “ingredients” as per the pool of products the user wants in his project.

Ordinarily, a typical user will be content of he can get the ingredient list exported, thereafter that information is no longer as important and will focus on the next project

[ThinhDinh]

Then what I would advise is first, apply row owners where you can because it seems like you consume a lot of rows for your functionality.

After that, use a third party service like Integromat or Zapier to periodically clears your database (in the Sheets) to free up some space, or use Google Scripts if you can do that to save cost.

[Keith_Chikumbirike]

Make thanks. All taken under advisement. I’ll explore the 3rd party option as I have no idea how to work with appscript

[Jeff_Hager]

Another idea.

Ideas for overcome the 25,000 rows limit in pro?

I created a request for this a while back: But…I recently had another thought about this. It’s not automatic and would take a little bit to set up, but I think a person could set up a single relation that gets the oldest row (prior to a certain date), and then add an action in a custom action somewhere in the app to delete the row through that relation. So you might have a custom action to show a detail screen, but you could add an additional action that would delete an old row as well. Th…

[Keith_Chikumbirike]

Ook…Still trying to understand this. lol

[nathanaelb]

User-specific column (USC)

• Personalization feature. Component personalization feature.
• Is applied to a basic column. Affects the attribute (column) of a list item, therefore a component.
• Personalization of a component that all users see.
• A specific item attribute (column) becomes personalizable, item by item (=row by row).
• Example: 1-to-5 star ratings (). If you rate a restaurant 4⭐, I might rate it 5⭐. Attribute personalization. Imagine that a cell in your table (Rating column of Restaurant ABC) is replicated like mirrors facing in an elevators. And this for every item on your list.
• USC creates cell depth.

Row owners

• Security feature. Performance feature. List personalization feature.
• Is applied to a column with email addresses. Affects list items (rows).
• Sub-lists of an entire list in your table are created. A sub-list is created based on the sub-list belonging to an email address (=user).
• Security: user A cannot see user B’s sub-list and user B cannot see user A’s sub-list.
• Performance: user A’s data is not downloaded to user B’s device, so less data is downloaded to devices, so performance improves.
• Example: The app contains a table called “restaurants”. Row owners is active. You add items restaurant A, B, and C to the list. I add restaurants D, E and F. (Regardless of USC which would apply to components) I will never see restaurants A, B and C in the app and you never D, E and F. Sure the app is personalized, but in a list level: we don’t see the same list items.
• Row owners (and “roles” for that matter) create row ownership (and ownership to a group or category of owners in the case of “roles”).

I hope this is clear enough and I didn’t make any mistakes.