# Best practices for handling multiple foreign keys to a single User Master table (role-playing dimensions)
**URL:** https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442
**Category:** Modeling
**Tags:** modeling
**Created:** [February 10, 2026, 4:45pm UTC](https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442 "2026-02-10T16:45:19Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@revati](https://community.omni.co/u/revati)
#### Post date: [February 10, 2026, 4:45pm UTC](https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442/1 "2026-02-10T16:45:19Z")
Hi everyone! We are looking for the most scalable way to model our User Master list in Omni.
Currently, our schema has multiple tables that reference the User table via different foreign keys. For example:
- **Tasks Table:** `task_created_user_id`, `task_completed_user_id`
- **Q&A Table:** `answer_user_id`
We want to avoid ‘view bloat’, creating a new User view/join for every single one of these specific use cases. However, the data needs to remain readable for Blobby and stay performant as we scale.
What is the recommended approach in Omni for handling these role-playing dimensions? Should we be leveraging specific join logic, Aliased Views, or is there a way to dynamically map these attributes without duplicating the User metadata dozens of times?
---
### Author:  [@colin](https://community.omni.co/u/colin)
#### Post date: [February 10, 2026, 4:59pm UTC](https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442/2 "2026-02-10T16:59:35Z")
What columns do you want to bring in from the users table for each of these? If it’s just a couple of fields vs multiple dependent views (ie user\_attributes\_1, user\_attributes\_2, etc).
A simple join-alias template may be a simple way to handle, but helps to have a bit more tangibility on what you need with each.
---
### Author:  [@revati](https://community.omni.co/u/revati)
#### Post date: [February 10, 2026, 5:24pm UTC](https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442/3 "2026-02-10T17:24:46Z")
It’s different for every use case but most of the times we have seen same 3,4 dimensions such the `user_name`, `user_role`, `user_market`, `user_creation_date` etc.
So you’re suggestion of join-alias template would still create multiple views right?
---
### Author:  [@colin](https://community.omni.co/u/colin)
#### Post date: [February 10, 2026, 5:44pm UTC](https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442/4 "2026-02-10T17:44:14Z")
Would still be a view you are joining in, but I think a template could simplify the whole thing. Need to test but if we write a template with the join, view + fields, then you’d be able to extend that template with a line just to direct to the desired key.
Much simpler example here: [How can I share logic across multiple models? (Hub and spoke)](https://community.omni.co/t/how-can-i-share-logic-across-multiple-models-hub-and-spoke/150)
> [@revati](#):
>
> So you’re suggestion of join-alias template would still create multiple views right?
---
### Author:  [@colin](https://community.omni.co/u/colin)
#### Post date: [February 10, 2026, 6:36pm UTC](https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442/5 "2026-02-10T18:36:18Z")
Actually looks like you don’t need templating, but dynamic renames are not as DRY as they could be. This would be the vanilla (bringing in views):
And the alternative if you can also extend group\_labels and nest them:
---
### Author:  [@revati](https://community.omni.co/u/revati)
#### Post date: [February 10, 2026, 7:56pm UTC](https://community.omni.co/t/best-practices-for-handling-multiple-foreign-keys-to-a-single-user-master-table-role-playing-dimensions/442/6 "2026-02-10T19:56:56Z")
So this is the screenshot of one of our existing Looker Explores.
`User` view: is the master user table
`Task Creators` and `Task Completors` views are derived from the `User` view but joined `user_id` on base view’s `creator_id` and `completor_id` fields to grab related id’s user information.
In a perfect world, we want to get away from creating multiple versions of the user views.
