for this week’s tip of the week, we wanted to share how you can add Custom Fields to your Users list that can unlock many interesting use cases.
to access Custom Fields for Users, you can navigate to https://{{instance_name}}.tulip.co/account-settings/users/fields (please note you need to be an Account Owner to access this). from here, you can add Custom Fields of different data types (Text, Number, etc.), and you’ll be able to assign each user a value for those each of those fields:
in this example, we’ll be assigning each user with a Department (Engineering, Production, QC, etc.) and using that to filter a list that we’re using in our App.
to start, you’ll need to create a Custom Field of Type Text, and name it Department:
Quick question; how do you manage to get the Name value put into the table?
Is there an easy way to do that for all the users, since you cannot get it from the user string (as it’s not a text variable).
@gio I think the question is more about how you take the user’s name and store it as a text type (e.g. not the User-type variable “USER 1” or the totext() random string ID, but taking User “John Klaess”, e.g. and making “John Klaess” as a string available in text type field.
Thanks for the clarification @John , that was exactly my question.
And thanks @gio for the response!
Even though I can see your logic, from a maintenance perspective, I don’t want the system to just log users who has logged in, but be able to see all users in the system table, and then being able to click them to add to the application roles table.
That is just impossible, because the users is not a text variable, but a random string. Isn’t there a way to make all the users into text easily? Like you’ve shown, you can add a name column next to the user column, but is there a easy way to transfer all the names into that column without having to manually type them all into the table?
would you mind sharing a little more on the use case?? we just want to make sure there aren’t alternative solutions that may work well before submitting a feature request.
also, I did want to clarify that using the Trigger Actin shared above, you won’t have to type the Name’s individually. this Field will be automatically maintained every time a user uses the App that has that Trigger.
Sure @gio, I will try to share so you might better see the context.
Within my application, I have created a user table for maintaining application roles. That table has a name column, which checks with the “logged-in-user” to see if it’s a match and if they have been given the correct Role in the Role column of that table. This table is maintained by the administrators, which are the only ones who can give out roles and permissions (see picture and number (4)).
Therefore, the users they might try to add to the application, might not have logged into the application just yet. But, if we can pull information from the Tulip user table, then we can see all users who have been created in the platform, and not just the ones who have logged in. Like this:
The problem then arises when I try to pull names out of the table; that when I click a user from the Tulip Table (1) which should populate a variable (2) used for checking the logged-in user, it instead gives me random characters because it’s a “user” variable and not a “text” variable. Therefore, the workaround of creating a column with the name as “text”, as you have done, is working. But that requires us to enter their name in that column, every time we create a new user, as it is not done automatically from the system.
Does this make more sense? I will include a picture of the application here as well:
hello @S.E.J, thanks for the clarification!! I certainly have a better understanding of it now.
just to confirm, is there a reason why you can’t store the Role and Site Name as a Custom Field in the Users Table?? just to clarify, the Users Table is the main Table used to manage Users within your account, where you can also add custom fields (such as Text) to dynamically store the data you’re mentioning:
The main reason for this is that we don’t want the application administrators to snoop around in our general tables. We would like to keep them application-specific so that administrators only have to maintain their specific applications and tables.
I see your point, and we’ve thought and discussed it. This would make it work but is just not the direction we chose to go. Therefore, the only problem right now, is that users are extracted as a random string. Everything else works perfect.
