Then I got the same effect by deleting the function “Make change to current user” from the workflow. I even deleted the fields “Model” and “Color” from the user data type and add constraints on the Repeating Group, to show only the data for the current user (Created by = Current user).
Hey Carlos “Make Changes to Current User” is the equivalent of “Make Changes to a Thing” (Thing to Change: Current User).
For example, if you have the field “Name” (type: text, list: no) within the User data type. Then an input where a User can enter their name, and click a button to save their Name - you could use either workflow to save that data change to the Current User:
Ohh! My apologies, I didn’t see that video before, but now I understand your question! In the video example, the Cars were created and then stored on the Current User in a list as well. Then in the repeating group, the data source came from the Current User’s List of Cars, instead of Doing a Search for Cars created by the Current User. Both will show the same results in the repeating group, in this example, but for querying and displaying very large lists, it’s faster to use Do a Search for method and add constraints to the search.
I wish I could be more helpful, but it really depends on the complexity of your app, how you think you will query the data when programming it, and how complex it might be in the future. I’m still learning how to do this, too! I would recommend reading Nigel’s posts in this thread here as they are extremely helpful in thinking about these topics early, so you don’t limit your app and then have to re-structure your data as the app becomes more complex. It really depends on the specifics of your app, but I think this thread might be helpful if you see your app having more complexity in the future, and don’t want to limit yourself in the beginning.
If you’re planning to have multiple levels of permissions you should probably include fields that explicitly state which user the data belongs to. If you rely on the user who created/modified the data, you might have all of your admins showing up in searches for user data because it’s the admin who created/modified the data.
So a field like “belongs-to=user” where you put the user who owns the data, rather than relying on the database’s built-in created-by or modified-by fields.
Lists seem to work really well if they don’t get too long. As a practical example, I’ve had batch changes I needed to make to 50K records. I had to break the searches up into lists only 1-2K items long otherwise they’d timeout and fail. But operations on lists that are 100 items long work fine.
So if your lists will never be longer than 100 items, you could build lists into your process. But if you’ll have more items than that you should rely on searches instead.