Forum Discussion
Assign rating to individual Choice items?
Hello, I'm trying to create a Sharepoint list of employees and their respective skills. Each skill has a rating from 1-4 indicating how proficient they are in it. Is there any way to implement this in a Sharepoint list besides manually creating 4 different versions of each skill? If not, is there a better way of implementing this? If possible, I want to keep this in Sharepoint to make it easy to access.
There are multiple ways to design this, and the right solution depends on how many skills you have, and based on exact use case.
Option 1 (OOTB): If the number of skills is small (e.g., up to 10 and common across all employees):
- You can create a single list with columns like:
- Employee (Person column)
- Skill 1 to Skill 10 (Choice 1,2,3,4)
- Each skill column can be a Choice or Number (1–4 rating)
For example:
Employee | SPFx | SharePoint | Power BI
User A (Email/Unique ID) | 3 | 4 | 2Option 2 (OOTB): If you have many or growing skill sets:
- Use a more scalable approach with separate lists:
- Skills list (all available skills)
- Mapping list or Employee Skills with:
- Employee (Person column)
- Skill (Lookup)
- Rating (Choice) (1–4)
This approach is more flexible and easier to maintain as your data grows. One row per employee + skill combination.
For example:
Employee | Skills | Rating |
User A (Email/Unique ID) | SharePoint | 4 |
User A (Email/Unique ID) | PowerBI | 2 |
User B (Email/Unique ID) | SharePoint | 1 |And you can use JSON formatting to improve UX by showing ratings Stars.
Option 3 (Low Code): OR you can Use Power Apps if your organization allows thisIf my post solved your issue or answered your query, please mark it as a Solution and give it a Like.
- You can create a single list with columns like:
5 Replies
How many skills can each employee have?
If it's a limited set of skills, like 10 or fewer, the best approach, as mentioned, is to create a dedicated column for each skill. This allows the skill level to be set using a number or selected from a dropdown menu.
Another case is when you have a massive variety of skills, and an individual employee might possess more than 10. In that scenario, you can go with the second option described by Virendrak, or leverage Power Apps and its linking records for instance.
Alternatively, you can test out Plumsail Forms, which handles can handle it in two ways: you can either store the skills and their corresponding levels inside a Data Table (repeating table) directly on the form, or connect the form to a separate SharePoint list and display them as related items.
There are multiple ways to design this, and the right solution depends on how many skills you have, and based on exact use case.
Option 1 (OOTB): If the number of skills is small (e.g., up to 10 and common across all employees):
- You can create a single list with columns like:
- Employee (Person column)
- Skill 1 to Skill 10 (Choice 1,2,3,4)
- Each skill column can be a Choice or Number (1–4 rating)
For example:
Employee | SPFx | SharePoint | Power BI
User A (Email/Unique ID) | 3 | 4 | 2Option 2 (OOTB): If you have many or growing skill sets:
- Use a more scalable approach with separate lists:
- Skills list (all available skills)
- Mapping list or Employee Skills with:
- Employee (Person column)
- Skill (Lookup)
- Rating (Choice) (1–4)
This approach is more flexible and easier to maintain as your data grows. One row per employee + skill combination.
For example:
Employee | Skills | Rating |
User A (Email/Unique ID) | SharePoint | 4 |
User A (Email/Unique ID) | PowerBI | 2 |
User B (Email/Unique ID) | SharePoint | 1 |And you can use JSON formatting to improve UX by showing ratings Stars.
Option 3 (Low Code): OR you can Use Power Apps if your organization allows thisIf my post solved your issue or answered your query, please mark it as a Solution and give it a Like.
Hi, thank you so much for your response. Regarding option 2, is there a way to implement this without have individual entries for each employee's skill? I want to keep the list clean and easy to read. Would it be a good idea to perhaps have a column for each possible rating, and add the corresponding skills to their respective ratings? For example:
Employee | 1 | 2 | 3 | 4 |
User A (Email/Unique ID) | | PowerBI | | SharePoint |
User B (Email/Unique ID) | SharePoint | | | 4 |Regarding option 3, could you elaborate on what implementing this using Power Apps might look like?
The approach you suggested can work, but there are a few considerations.
If you're not using Power Apps and users are entering data directly through the SharePoint UI, you would need to create four columns (Rating 1, Rating 2, Rating 3, and Rating 4). These will be multi-select Choice columns, each column would contain the same list of skills.
The challenge is that out-of-the-box SharePoint doesn't provide a way to prevent users from selecting the same skill in multiple rating columns. For example, a user could select SharePoint under both Rating 1 and Rating 2, which would impact data integrity and make reporting less reliable.
Another option would be to use multi-line text columns, but I would not recommend that approach. It would rely on users manually entering skill names, which can lead to spelling differences, inconsistent naming, and reporting challenges.
With the approach I proposed (Option 2), each employee-skill-rating combination is stored as a separate record:
Employee | Skill | Rating
---------- | ------------- | ------
User A | SharePoint | 4
User A | Power BI | 2
User B | SharePoint | 1This ensures users can only assign one rating per skill, maintains data integrity, and scales well as the number of skills grows.
Although the underlying list contains more records, you can present the data in any format you want using Power BI. For example, Power BI can display it as a matrix showing employees on one axis and skills on the other, giving you the same clean view while keeping the source data structured and easy to maintain.
For that reason, I would still recommend the OOTB approach, as it aligns with your requirement of implementing the solution within SharePoint Online. While it results in more rows in the list, it provides better data integrity, simpler filtering, and greater scalability as the number of skills grows. It also avoids the need for custom Power Apps logic. Reporting and visualization can then be handled efficiently in Power BI, where the data can be presented in a more user-friendly format.
Regarding Option 3 (Power Apps)
Once you start using Power Apps for data entry interface and Power Apps OR Power BI for reporting, the solution is often referred to as low-code or no-code, but technically it still requires application logic, testing, and ongoing maintenance.
With your proposed one-row-per-employee approach, it is certainly possible to build a Power Apps interface that prevents users from selecting the same skill across multiple rating columns. For example, if a skill has already been selected under Rating 1, the app could hide or disable that skill in the other rating fields.
However, that requires implementing custom validation and business rules within Power Apps. At that stage, the solution becomes more of a custom application rather than a purely out-of-the-box SharePoint implementation. Every validation rule, UI enhancement, and future change would need to be maintained within the app.
The Option 2 OOTB approach I suggested focuses on keeping the data structure simple and enforcing data integrity at the source. Your approach focuses on providing a cleaner user experience and can work very well when paired with Power Apps. The trade-off is that you are moving some of the complexity from the data model into the application layer.
- Your approach: A cleaner list with one row per employee, but regardless of whether you use multi-select Choice columns or multi-line text columns, it relies on Power Apps or other custom logic to enforce data integrity and prevent duplicate skill selections across rating categories. Without that additional logic, users could assign the same skill to multiple ratings, leading to inconsistent data and reporting challenges.
- Option 2 (OOTB approach): While this approach results in more rows in the list, it provides better data integrity, is easier to maintain as the number of skills grows and supports reporting in Power BI without requiring significant custom logic.
From a SharePoint perspective, you can also configure the list so that users can only create and edit their own records by using Item-level Permissions ("Users can read/edit only their own items"). This helps ensure employees can manage only their own skill entries.
In addition, you can create a view filtered on:
Employee = [Me]
This gives each user a simple view showing only their own skills and ratings, while administrators or managers can have separate views that display all records.
If Power Apps is already part of the solution and you're comfortable maintaining the application logic, then the one-row-per-user approach is absolutely a viable option. Just keep in mind that it shifts complexity from the data model to the application layer and becomes more of a custom solution than an out-of-the-box SharePoint solution.
- You can create a single list with columns like:
