Enable condition builder on survey scorecard for user (role: survey user, non-admin)

[AlexandraSz]

I need to create a survey for a client using a course management application. A Proof of Concept (POC) is already done; I tested it using my own user account, and I have admin rights (which will be important later). During the demo, I accessed the "View Scorecard" feature (`assessment_scorecard.do`), 

and a filter appeared allowing searches among the question results.

The client said this wasn't sufficient because they need to filter by course name. We decided that using the condition builder would work if I could somehow include the course name in that table. So, I solved it: I checked the table for the condition builder (`asmt_metric_result`) and used a business rule to populate the course name upon record creation, which enabled the filtering. The problem is that the condition builder doesn't appear for users with only "survey reader" rights—it only shows up for me because I'm an admin. I can't grant the user "survey admin" or "assessment admin" roles; only "survey reader" is permitted. Does anyone have any ideas? I’d prefer not to use a dashboard for this since ServiceNow already has this out-of-the-box (OOB) functionality.
Admin user see this:

Survey reader user see this and they don't see the condition builder:

Unfortunately, creating separate surveys for each type isn't a solution, because there are 1,500 varieties.

[Kieran Anson]

In order to view the condition builder, you must have read access to asmt_condition. 

Adding the following ACL would allow access

[sachinvic]

HI @AlexandraSz,

The survey_reader role is strictly designed for read-only access to surveys, responses, and scorecards. While users with this role can view the scorecard UI, the Condition Builder itself is often restricted by OOTB UI policies or underlying table-level access.

Before jumping to ACL changes, I'd recommend checking the security configuration for the asmt_metric_result table and the scorecard page itself. In my experience, if the Condition Builder is hardcoded to require elevated roles in the baseline UI, creating custom ACLs or roles alone might not make it appear.

Instead of fighting the OOTB scorecard UI, a cleaner workaround is to create a custom report or Database View built on the asmt_metric_result table. Since you've already populated the Course Name, you can easily expose a filtered report to these users. This keeps your survey_reader permissions intact and secure.

I would strongly advise against granting survey_admin or assessment_admin just to get the Condition Builder back. Those roles grant massive administrative privileges that a standard reader shouldn't have.