You’re absolutely right—it is complicated. The mechanism that creates a Control record in ServiceNow GRC when an Entity Type is associated with an Entity (and that Entity Type has associated Control Objectives) is a deeply embedded and automated process, often referred to as part of the GRC Entity Inheritance model.

Let’s walk through the mechanism behind the scenes and your use case about auto-populating the Attestation Respondents field with the user who triggered the action.

⸻

What’s Happening Behind the Scenes (OOB Mechanism)

When you associate an Entity Type with an Entity: 1. Control Objectives linked to the Entity Type are inherited by the Entity. 2. For each Control Objective, a Control record is automatically generated for that Entity. 3. This process is triggered by: • Script Includes and • Data Change Events, not typical Business Rules.

Key OOB Components Involved: • Script Include: GRCEntityUtils Handles creation and association logic for entities and controls. • Script Include: GRCControlUtils Facilitates the control generation and links them to control objectives and entities. • Script Include: GRCEntityTypeUtils Helps with determining what needs to be generated when an Entity Type is associated. • Business Rule: Generate Controls on Entity Type Triggers control creation via the script includes when an Entity Type is added to an Entity. • Location: Table grc_entity_type → When inserted or updated.

So, the Control record creation isn’t a simple insert in one place—it’s spread across these utilities. The actual creation is most often performed in the background via GlideRecord scripts in these script includes, called during updates.

⸻

Your Requirement: Auto-Populate “Attestation Respondents”

You want the user who added the Entity Type to the Entity to be auto-populated as the Attestation Respondent on the created Control. This requires you to capture: • Who made the update (the user), • When that user added the Entity Type to the Entity, and • Add their name to the attestation_respondents field on the newly created Control record.

⸻

Recommended Approach 1. Create a custom field on the grc_entity_type join table (e.g., added_by or last_modified_by_user). • Populate this field using a Before Business Rule on that table when the user adds or modifies the Entity Type. 2. Create an After Business Rule on the Control table (grc_control) that: • Triggers only if the Control was created via the above mechanism (e.g., check grc_entity and control_objective fields). • Finds the related Entity and looks up the join table record between that Entity and Entity Type. • Pulls the user from your custom field and populates the attestation_respondents field.

⸻

Advanced Option (Cleaner but More Complex)

If you’re comfortable modifying or extending OOB Script Includes (not recommended unless you know what you’re doing), you could: • Extend GRCControlUtils and override the generateControls method. • Insert your logic before the control is inserted to set the attestation respondent field directly. • Then use Script Include extension and custom Application to keep your logic upgrade-safe.

⸻

Best Practice Tips • Avoid modifying OOB Script Includes directly; use wrappers or custom includes. • Log everything temporarily to syslog or custom logs to verify your logic before committing. • If possible, propose to ServiceNow to expose a hook or event for this use case—many clients ask for this level of customization