Attribute Rules Permission

Question

My GIS team is unable to add attribute rules to our data in ArcGIS Pro because we do not have administrator/data owner privileges. Esri Support informed us that system admin privileges are required to create or manage attribute rules.

Can anyone explain why this restriction exists? Since attribute rules are commonly used for data validation and automation, we're curious why non-admin GIS users cannot create or modify them. Is this related to geodatabase schema changes, security, licensing, or something else? Is there another way in which the GIS analysts can add attribute rules?

Thank you

Robert_LeClair · Answer

Question:  Are you using an Enterprise GDB or a File GDB?  For an Enterprise geodatabase you must be the data owner. To create or manage attribute rules, you must access the Attribute Rules view “from the geodatabase as the data owner.” If you connect as a user who is not the data owner, the Attribute Rules view is read-only. It’s also read-only from a web feature layer.  In addition, the Attribute Rules view is read-only when accessed with an ArcGIS Pro Basic license.

MErikReedAugusta · Answer

I can't speak for the reasoning of ESRI's designers, but I've always viewed Attribute Rules as being sort of similar to a domain.

In the stormwater dataset I help maintain for our organization, we developed a shorthand for what we called "Hard Domains" and "Soft Domains".  Originally, Hard Domains were things implemented as actual Domains and/or Subtypes, and were baked into the schema.  Soft Domains were rules folks were expected to follow, but that weren't enforced at software level.

A great example of a Hard Domain would be a list of valid pipe materials, and a common Soft Domain for us was the specific formatting of an Asset ID.

For a while, those IDs had to be hand-populated and we just had to hope everyone was following the rules and not making mistakes.  Now, we've finally been able to deploy Attribute Rules that generate those IDs.

From an end-user standpoint, that means the IDs are enforced and restricted by the software kinda like the pipe materials are.  The Attribute Rules for the IDs aren't technically "domains", but in a lot of ways, they're functionally similar.  We also have other Attribute Rules for non-ID fields, and nearly all of them are serving this "quasi-/soft domain" functionality.  And all of that is before we get into things like Contingent Values and Validation Rules, which technically also fall under the broader header of attribute rules, and are more explicitly domain-like.

So in that light, I think it makes more sense for them to only be able to be altered by someone with admin privileges.  There are rare cases when a workaround calls for temporarily disabling an attribute rule, and I have mixed feelings on who should be able to do that.  For now, though, I'm content to restrict that to those of us with admin rights.