I have used USC and also on a number of occasions the community as referred me to use USC for some of the solutions, however I still do not fully connect all the dots as to WHY I need to use the USCs. I am unable to find any detailed document to help me understand.
My current understanding :
A case for where you different users are adding comments or “likes” to a record, you don’t want to replicate the row and can just overload a cell.
I have used it and been advised to use it when I am doing forms, but only for a temporary period until the user does a submit and then clear out the USCs and add row to a persistent table. I have done it but I don’t fully understand why I should use the USCs in this case and then why do I need to add the row to another table and delete the USC, why not keep them in the USC.
I sort of know how to use them, but not sure why i’m using them and/or when to use them.
I guess to answer this I first need to point out one very important difference between native and custom forms to add new rows. With a native form (ie. Show Form Screen), the values that a user enters are held in memory, and are only submitted to the table once the user submits, at which point a new row is created.
However with a custom form - which is basically just a details layout with one or more input components - any values entered are immediately written to the columns associated with the input components. This is why you must always use User Specific Columns, otherwise you’ll be clobbering existing data. It’s also why you need an explicit Add Row action with a custom form.
One of the big advantages of this is that because the data is written to the table before the form is submitted, you can use it make decisions about what needs to be done based on the data that’s being entered. A common use case is to build relations to existing data for the purpose of detecting potential duplicate records. Another use case is using the entered data to compute other values that can be used with the final form submission. Neither of these options are available when using native forms.
As to whether to clear the user specific columns after the new row is added, that really depends on the use case. I’d say in most cases it makes sense to do so, but there can be times where you might want to leave it there. The thing to understand is that if you don’t clear the values, then the next time that same user (assuming it’s a signed in user) opens that same form - all components will be pre-populated with the values from their previous submission. In most cases you won’t want this. Or you might want to leave one or more of them as “default” values for next time. It depends.
One situation where you probably wouldn’t clear user specific columns is when you’re using them to dynamically filter an inline list. Imagine that you have a catalog of cars, and you want to present them as an inline list. But you might also want to allow users to dynamically filter the list; by make, model, number of cylinders, whatever. A common way to do this is to add a choice component for each filter option and target those at user specific columns. Then as a user makes choices you can take the values from the user specific columns and use them to create dynamic filters. And because they are user specific, each user sees their own customised filtered view of the data. With a use case such as this, you probably wouldn’t bother clearing the user specific columns, so that whenever a user returns to the list they will get the same filtered view that they had the previous time.
Another advantage of user specific columns is that they help prevent users from tripping over each other. Imagine if in the above scenario you were writing the choice components to basic (non-user specific) columns. Then as each user applied a filter the value would change for all users (once the change had synced).
One more advantage of User Specific Columns is that you can set them as part of an action sequence for presenting a form to create a set of preconditions, which will in turn determine what the user sees.
Yet another useful feature of user specific columns is that because they are computed columns, they will never appear in your Google Sheet. I like to take advantage of this and often have user specific columns in my User Profiles table (even though I don’t need them, as I’m using Row Owners) simply because I don’t want/need the extra columns in my Google Sheet.
I kind of view User Specific Columns as a temporary storage area, and I find them incredibly useful.