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).
What, after all, is the utility of the function “Create change to current user”?
Note: I will have 3 types of users; Admin, Manager and Viewers (or visitors, who eventually will make small changes to the data; as download docs, send messages, …).
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:
This question is due to my doubt. To control who owns the data (users) I really need to use this function or if I can get the same results with the method I used in the experiment I reported.
Is there a difference between the two methods, so that I must choose one over the other, or is it indifferent to use?
Since I’m at the beginning of the process, now is the time to decide which one to use.
Will I have problems if I choose not to use “Make change to current user”?
If so, what are they?
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.
As I said in the post, I have 3 levels of users; Admin, Manager and Viewers.
The last users, the 3th level, will always have data related to payments. Only a few of them will have access to view their current accounts, and this will only happen later.
Payments are monthly and so the lists will never be too long.
So, and following what you wrote, @fayewatson and @blueback09, I think it works well without using “Make Changes to Current User”.
“Make Changes to Current User” is the equivalent of “Make Changes to a Thing” (Thing to Change: Current User).
