Typically we use the data item User for storing properties of our users. This is convenient: all user-properties are in the same place.
But there are some disadvantages to this setup:
Maybe not all persons using the application need a user account. Think of one-time-only webshop customers or contact persons of a CRM system.
You cannot “take over“ a user account to see what the user sees (because you need the login credentials of the customer or employee for that). This can make it difficult to help users without sharing a screen.
Changing the email address of a user is complicated: first create a new user. Then all data and references of the old user must be copied to the new one and the old user must be blocked. Then the data and references of the old user must be cleared.
The solution is to create a data item Person that will be linked to the user. Now:
The person only gets a user account when he needs to be able to login.
A supporting user can take over the account of the person he is helping. This way he can see and do exactly what this person can see and do.
The person can change his email address easily: create a new user, link the person to the new user and block the old user. The person gets a new activation mail and from then on he can use his new email to sign in.
Step 1: create the data item Person
Save the current version.
Create data item Person.
Add a 1-1 reference to User. Name it My account, in data item User, name it Person that owns the account. When a person is taken/taking over, the owner of the account is stored here temporarily.
Add another 1-1 reference to User. Name it User, in data item User, name it Person. This reflects the link that normally exists between the user and the person.
Add the properties that you will remove from the data item User.
Create a user flow for Personand include it in Appearance.
Tip: Don’t adjust the related flows yet: after you delete properties from the data item User (see below), Triggre will show you where you have work to do.
Step 2: transfer the data from User to Person
There are two options, depending on how much data you have to transfer.
Build a flow part to copy the data from User to Person. This option is our favorite, because all data stays within the application and it saves a lot of hassle.
Create a flow part with a repeat action that copies the data in data item User to the related person. You can find an example of such a flow part below.
Modify the Admin user flow: add a button that triggers this flow part.
Save the current design. In case you need to revert to it.
Publish the design.
Activate the flow part.
Check the data in user flow Persons.
Export the data from User and import them in Person. This is the option we don’t advise you to use, because you might end up with a lot of manual actions.
Be sure that you allow import in Person.
Be sure that you have a user flow available from which you can export all user-data that you want to import in Person.
Save the current design. You might need to revert to it.
Publish the design.
Export the user-data.
Adjust the Excel to the design of Person (don’t forget to rename Email to Email [ID] and to rename the sheet to Person).
Import the sheet into Person.
Step 3: delete the transferred properties from the data item User
Save the current version. You are about to remove properties from the data item User. You definitely want to be able to undo these changes if you find out you did something wrong.
Remove the properties in User that you added to Person. This will probably result in broken items in flow parts and user flows.
Step 4: correct the ‘red’ design items
Check the designer for red dots.
Correct the items with red dots.
An example: you transferred First name from User to Person. Now the flow part that generates the full name lacks some data.
After making all the changes, save the current version and publish the design.
Example of the transferring flow part
Create the flow part
Add a look-up of all users.
Add a repeat action, based on the look-up.
Design the repeat action
Create the related person.
Copy all properties of the user to this person.
For every referenced property, add a look-up list. Example: invoices.
Store the person in all these invoices:
Which email to use?
Since the email will be available in both User and Person, you have to decide which one you will use in user flows and flow parts. Both should be identical. We advise you to use Email in Person, because when you have persons in your system without a user account, only the Email in Person is available.