SAML attributes now become lists when your identity provider sends more than one value
Published: September 2, 2026
SAML does not have a way to say that a claim holds exactly one value. Every claim arrives as a list of values. Sanity looks at how many values it receives and infers the type of the attribute: one value becomes a single value, and two or more values become a list.
This means that a single-value attribute is a temporary state. It shows that no member has signed in with two values for that claim yet. It does not show that the claim can only hold one value.
Before this change, a member who signed in with two values for a claim got a type conflict, and the attribute did not update. Now Sanity changes the attribute to a list, and keeps the values of all other members. The change applies to the whole organization, because the attribute is shared by all of its members. The change to a list is permanent for that attribute. A later sign-in with one value does not change the attribute back to a single value.
What you must do: Look at your Content Resource filters that use user::attributes(). If a filter compares a SAML attribute to an exact value, change it to test for list membership. Use this form:
// Fragile: fails after the attribute becomes a list. user::attributes().department == "Engineering" // Recommended: works for a single value and for a list. "Engineering" in coalesce( user::attributes().department[], [user::attributes().department] )
A filter that grants access can start to deny access if you do not update it. The values of your members do not change: only the shape of the values changes.