IdentityIQ-Associate SailPoint Certified IdentityIQ Associate

No. Marking an attribute as multi-valued does not, by itself, cause IdentityIQ to treat that attribute as an entitlement or include its values in the Entitlement Catalog.

In an application schema, the multi-valued setting only indicates that the account attribute can contain more than one value. It describes data structure, not governance meaning.

To include access values in the Entitlement Catalog, the relevant schema attribute must be configured as an entitlement-bearing attribute, or group objects

must be properly configured and aggregated through the application’s group schema where applicable. IdentityIQ then

recognizes those values as governable access rights and can represent them as managed attributes in the Entitlement Catalog. Once cataloged, they can be

reviewed, certified, requested, described, owned, risk-scored, and governed by policy.

For example, an account attribute such as “groups” may be multi-valued, but IdentityIQ must also know that those

values represent access rights. Without entitlement configuration, the aggregation stores attribute values

on the account but does not properly model them as catalog entitlements.

Reference topics: Access Modeling, Entitlement Catalog, managed attributes, application schema attributes,

entitlement attribute configuration, group schema, and account aggregation

The statement is false. The Identity Refresh task is used to update and recalculate identity-related data in IdentityIQ, not to manage open work

item reminders. Its purpose is to refresh IdentityCubes after aggregation or identity data changes. Depending on selected task options,

Identity Refresh can recalculate identity attributes, apply correlation-related updates, refresh role assignments and detections, evaluate

policies, process lifecycle events, update risk-related data, and ensure that the identity model reflects the current state of authoritative and application data.

Open work items belong to IdentityIQ’s workflow and governance execution layer. Reminders, escalations, expirations, and related work item follow-up behavior are handled through work item configuration, workflow behavior, certification configuration, and maintenance-style processing rather than the Identity Refresh task. Although Identity Refresh may trigger

downstream actions such as lifecycle events or policy evaluation, it is not the task responsible for notifying users about pending approvals or review items.

Therefore, sending reminders for open work items is outside the purpose of Identity Refresh. Reference topics: Identity

Modeling — common Identity Refresh options; Foundational Concepts — tasks versus workflows; Governance — work items,

certifications, reminders, and escalation behavior.