Roles can be tricky to represent in a model. A person might be a project manager for organization A, but simply creating an element type "Roles" and connecting it to Users and Organizations isn't enough. What happens when a new person comes into the City and selects "Project Manager" for their role, we need to know that they are a project manager for a different organization. Roles are not the only potential element type that can encounter this problem, any element that has a meaning only in a specific case or context will suffer from this. For our role example, a role within an organization is only valid for that organization.


This article will stick with the "Role" example and discuss how to set this up in a City Model so that a user filling out their onboarding from will be connected to a role appropriately. Bulk importing has slightly different considerations that will be address briefly at the end of the article.


The first thing we need to do is the step that's not enough, create a Roles element type and connect it to City Users and Organizations.



As pointed out earlier though, this is not enough. The main issue is that only the first user to create a role can specify which organization it belongs to. Subsequent users would simply be connected to that existing role. What is needed then is a way to create a unique role each time, regardless of if it's name matches an existing role.


There is a connection field user interface type that solves this issue; the Tabular 


You will also normally want to check the "Allow Edit Connection" and "Allow Delete" options, otherwise there is no way for the user to remove their role.



This will result in a simple, empty role table as you can see below.

Clicking "Add" will open the form for the Role, which allows the user to connect the role to the appropriate organization:


Adding additional roles, or roles added by different users are kept completely separate, preventing issues where one user accidentally connects to a role of a different user creating confusion about which user is in the role for which organization.



This is useful for any case where you need a user to enter information that might "match" other information in the system but needs to be kept separate, roles are just one example that comes up.


If you have questions about how to set this up, please ask on our forums or create a ticket for our support team.




Bulk Imports: If doing this via a bulk import the best way is to create a hidden "identifier" field that has a combination of the role name and the organization name, then make sure the Model is set up as described above so that user is able to properly manage their roles via the forms.