why assessor or requestor fields are not present in smart assessment record

[jhonadel]

We wanted to show assessor and requestor in the list view of smart assessments but I can't find those fields in the record. How to achieve it?

[Vikram Reddy]

Hi @jhonadel,

The short version: the smart assessment instance record (table sn_smart_asmt_instance) is built to be source agnostic, so it doesn't carry its own assessor or requestor fields. Smart Assessment Engine can be triggered from almost anything: an incident, a risk, a control, a case, an HR case. Instead of duplicating "who requested it" and "who's assessing it" onto every instance, that identity stays on whatever record triggered the assessment, and the instance just holds a link back to it (usually the Trigger record or Trigger ID field). You see the same pattern with Entity and Control on GRC assessments: those aren't on the base form either, they render in the side panel and are actually stored in a separate relationship table, sn_smart_m2m_instance_scope_item.

That link-back is also where people usually get stuck, because in a lot of implementations the trigger reference is a Document ID (polymorphic) field rather than a plain Reference field, and Document ID fields can't be dot-walked for display or filtering in list views. That's a platform limitation, not something you're missing in config.

Before you assume the data isn't captured at all, work through this:

• Configure > List Layout on sn_smart_asmt_instance: check whether the trigger/source link even appears as an available column, and note if it's typed as Reference or Document ID.
• Side panel on the assessment instance: assessor and requestor context tied to the source record often renders there instead of on the base form.
• Related list for the trigger record on the instance form: if it's present, that confirms the link exists, you just need another way to surface it, not that the data is missing.
• Trigger table consistency: if your smart assessments fire from more than one table (incident vs case vs risk), a single dot-walked field won't work cleanly anyway since the requestor field name differs per source table.

If the trigger field really is Document ID typed, dot-walking it into the list view won't work no matter how you configure the layout. The reliable fix is a small business rule (on insert, or hung off the trigger flow) that reads the source record off the trigger id and copies the assessor and requestor values into two plain reference fields you add to sn_smart_asmt_instance, then those go into the list view like any other field. It's a bit of scripting, but it survives regardless of which table triggered the assessment.

One caveat: Smart Assessment Engine ships slightly differently across GRC, FSM, and ESG or TPRM, so confirm sn_smart_asmt_instance is actually the table backing your list before writing that business rule. Some older assessments still run on the legacy asmt_assessment_instance table, which has trigger_id, trigger_table, and trigger_condition fields with the same dot-walk restriction.

Thank you,
Vikram Karety
Octigo Solutions INC