"}],"short_description":"Temporary disable all attribute rules in the Geodatabase","flexible_content":[{"acf_fc_layout":"content","content":"Customers can author their data quality business logic as Attribute Rules<\/a> to prevent users from making incorrect edits to the system. This improves data quality, avoids accidental editing mistakes, and simplifies subsequent downstream QA\/QC workflows. This is commonly done using Constraint Attribute Rules which rollbacks edits that violate the user logic.<\/p>\n However, there are cases where certain types of users, such as Admins and Supervisors, need to temporarily bypass rules so they can later apply more holistic checks. Moreover, there are always exceptions that either were not considered when the rules were authored or were discovered later, that requires the rules to be bypassed. That is why the ability to disable attribute rules has been a recurring question we frequently get.<\/p>\n In this blog, I will go through four different ways to either disable or skip Attribute Rules execution in the geodatabase:<\/p>\n Using Python to disable all Attribute Rules in a Workspace<\/p>\n<\/li>\n Using a config table to bypass Attribute Rules execution<\/p>\n<\/li>\n Allowing Admins to bypass Attribute Rules<\/p>\n<\/li>\n Allowing users in a specific group to bypass Attribute Rules<\/p>\n<\/li>\n<\/ul>\n Let\u2019s get started.<\/p>\n"},{"acf_fc_layout":"content","content":" This is the obvious first choice when needing the skip Attribute Rule execution. The geodatabase provides a way to disable one or more attribute rules for a given class via the Disable Attribute Rule<\/a>s geoprocessing tool. Users can script this in Python to loop through all desired classes, read all the rules for each class, filter the rules by type and call Disable Attribute rules with the list of rules they wish to disable. Once the edits are finished, users can re-enable the rules by running the same script but calling Enable Attribute Rules<\/a> instead.<\/p>\n Here is a sample python script that disables and enables all rules. Note this is written so it only disables constraint attribute rules, but you can remove that condition to disable all rules.<\/p>\n"},{"acf_fc_layout":"sidebar","content":" Disable All Constraint Attribute Rules<\/p>\n","image_reference":false,"layout":"code_snippet","image_reference_figure":"","snippet":"import arcpy\r\n\r\ngdb = \"PATH_TO_WORKSPACE\"\r\n\r\ndef modify(table):\r\n rules = [r.name for r in getattr(table, \"attributeRules\", []) if r.type == \"esriARTConstraint\"]\r\n \r\n if rules: \r\n print(f'Disabling rules on {table.name} {rules}')\r\n #arcpy.DisableAttributeRules_management(table.catalogPath, rules)\r\n print(arcpy.GetMessages())\r\n\r\nfor child in arcpy.Describe(gdb).children:\r\n modify(child)\r\n for grandchild in getattr(child, 'children', []):\r\n modify(grandchild)\r\n","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"sidebar","content":" Disable All Constraint Attribute Rules<\/p>\n","image_reference":false,"layout":"code_snippet","image_reference_figure":"","snippet":"import arcpy\r\n\r\ngdb = \"PATH_TO_WORKSPACE\" \r\n\r\ndef modify(table):\r\n rules = [r.name for r in getattr(table, \"attributeRules\", []) if r.type == \"esriARTConstraint\"]\r\n \r\n if rules:\r\n\tprint(f'Enabling rules on {table.name} ')\r\n arcpy.EnableAttributeRules_management(table.catalogPath, rules)\r\n print(arcpy.GetMessages())\r\n\r\n\r\nfor child in arcpy.Describe(gdb).children:\r\n modify(child)\r\n for grandchild in getattr(child, 'children', []):\r\n modify(grandchild)\r\n","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":" The downside for running this script is it requires an exclusive lock to execute. That means if the table where the attribute rules live is opened by a session, whether this is in Pro or a process on the service, the python call fail. Which means all services and ArcGIS Pro sessions must be closed to run this script, which might not be ideal. Another drawback to this is the script doesn’t know what rules were initially disabled and what were disabled by the script. So re-enabling all rules may accidentally enable rules that were disabled on purpose causing other issues.<\/p>\n I would not recommend Let us explore another more approach to perform this.<\/p>\n"},{"acf_fc_layout":"content","content":" The other approach is to allow users to disable Attribute Rules by adding an Arcade condition to every rule to check if the rule should be executed. The Arcade logic queries a configuration table, reads a specific settings and determines if the rule should run. While the rules remain physically enabled in the geodatabase and do execute, the new condition causes an early exit from the rule, effectively simulating the rule being disabled. Let\u2019s implement that.<\/p>\n Create a new table in your geodatabase with two columns: Create a new row in the table where Now, for every rule we wish to dynamically disable or skip, we can add a single line of Arcade that checks the config table and determines whether the rule should continue executing or not.<\/p>\n"},{"acf_fc_layout":"sidebar","content":"","image_reference":false,"layout":"code_snippet","image_reference_figure":"","snippet":"var c = First(Filter(FeatureSetByName($datastore, \"ARConfig\") , \"config_name = 'disable_rules' and config_value ='true'\"));\r\n\/\/Skip the Attribute Rule execution \r\n\/\/If this is a calculation rule use return; \r\n\/\/If this is a constraint rule use return true;\r\nif (c) return true; \r\n\r\n\/* The rest of the rule *\/","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":" The sky is the limit with this approach. You can make this configuration global for all users, or control it per user role or group. You can also lock this table so that only admins can edit it. This way no one by admins can globally disable Attribute rules.<\/p>\n This is applicable to Attribute Rules on all workspace types. One thing to note for services on ArcGIS Enterprise, it is recommended to publish the config table to the service, especially if there are rules that are executed client-side. That said, you don\u2019t have to publish the config table as long as you ensure that all rules where the config check is applied are excluded from client evaluation<\/a>.<\/p>\n The drawbacks of this approach are the need for an additional table, updating all rules, and republishing services.<\/p>\n Let us explore another approach where we don\u2019t need an extra table.<\/p>\n"},{"acf_fc_layout":"content","content":" It is useful to allow administrators to bypass attribute rules, especially when a given rule cannot be met. This approach doesn\u2019t require a config table; instead, it simply involves adding a single line of Arcade code to every Attribute Rule you want admins to bypass. This method uses the \n
Using Python to disable all Attribute Rules in a Workspace<\/h2>\n
Using a config table to bypass Attribute Rules execution<\/h2>\n
config_name<\/code> of type text and config_value<\/code> of type text. You can name the table anything you like; I called it ARConfig<\/strong>.<\/p>\nconfig_name<\/code> is \"disable_rules\"<\/code> and config_value<\/code> is \"true\"<\/code>.<\/p>\n"},{"acf_fc_layout":"image","image":{"ID":2952831,"id":2952831,"title":"congi","filename":"congi.png","filesize":63996,"url":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi.png","link":"https:\/\/www.esri.com\/arcgis-blog\/products\/arcgis-pro\/data-management\/dynamically-disable-all-attribute-rules\/congi","alt":"","author":"7511","description":"","caption":"","name":"congi","status":"inherit","uploaded_to":2952816,"date":"2025-12-30 15:54:09","modified":"2025-12-30 15:54:09","menu_order":0,"mime_type":"image\/png","type":"image","subtype":"png","icon":"https:\/\/www.esri.com\/arcgis-blog\/wp-includes\/images\/media\/default.png","width":486,"height":538,"sizes":{"thumbnail":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi-213x200.png","thumbnail-width":213,"thumbnail-height":200,"medium":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi.png","medium-width":236,"medium-height":261,"medium_large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi.png","medium_large-width":486,"medium_large-height":538,"large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi.png","large-width":486,"large-height":538,"1536x1536":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi.png","1536x1536-width":486,"1536x1536-height":538,"2048x2048":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi.png","2048x2048-width":486,"2048x2048-height":538,"card_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi-420x465.png","card_image-width":420,"card_image-height":465,"wide_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2025\/12\/congi.png","wide_image-width":486,"wide_image-height":538}},"image_position":"center","orientation":"horizontal","hyperlink":""},{"acf_fc_layout":"content","content":"Allowing Admins to bypass Attribute Rules<\/h2>\n
GetUser<\/code> <\/a>Arcade function, which returns the current user along with their groups, roles, and privileges, and checks whether they are an admin.<\/p>\n"},{"acf_fc_layout":"sidebar","content":"","image_reference":false,"layout":"code_snippet","image_reference_figure":"","snippet":"\/\/Skip the Attribute Rule execution if the user is an admin\r\n\/\/If this is a calculation rule use return; \r\n\/\/If this is a constraint rule use return true;\r\nif (getUser()[\"role\"] == \"org_admin\") return true;\r\n\r\n\/* The rest of the rule *\/","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":"