ArcGIS Pro geodatabase guardrails are not interchangeable — what domains, subtypes, contingent values and attribute rules do when a script writes the data

On September 16, 2026, the ArcGIS Blog published Esri’s advice on building better data management workflows in ArcGIS Pro, and its central move is to put repeatable decisions into the data model. It gives each control a job: “domains limit individual values, subtypes organize categories of features, contingent values manage valid combinations, and attribute rules apply logic.” The documentation agrees with that division of labor. What the blog does not answer is the question that matters the day a script loads the data: which of these controls stops a bad value that never went through an editing form?

We read every control against the ArcGIS Pro 3.7 documentation, then measured every control except batch calculation rules on a file and a mobile geodatabase. We did not build a batch calculation rule, so what we say about that rule type is documented, not measured. Where we say measured, we ran ArcGIS Pro 3.7.1 (build 1901, Advanced license) against a fresh file geodatabase and a fresh mobile geodatabase, and both gave the same answer unless we say otherwise. We had no enterprise geodatabase and no ArcGIS Enterprise, so everything we say about those is documented, not tested.

The short answer: at the tools’ defaults, domains, subtypes and contingent values stopped none of the bad values we wrote with an arcpy.da.InsertCursor, the Calculate Field tool or the Append tool. A constraint attribute rule stopped the violating writes from all three. ENFORCE_DOMAINS, an option on the Calculate Field, Calculate Fields and Append tools, changes that for domains, and only for domains — and on a range field with a default, Append replaced a refused value with one that still broke the domain.

Six controls, three points where they act

Attribute rules come in three types — calculation, constraint and validation — and a calculation rule can be immediate or batch. Esri’s overview calls attribute rules “complementary to existing rules used in the geodatabase, such as domains and subtypes,” not a replacement for them. Here is what each control does and when the documentation says it acts.

Read the last column again. Domains and contingent values act at the same point, inside the editing application (the Attributes pane and the table view, what the rest of this post calls the editing form). Immediate calculation and constraint rules both act on the edit itself, calculation first. Batch calculation and validation rules wait until someone evaluates them. Subtypes are not an enforcement point at all: they supply the categories, the defaults and the per-subtype domains that the other controls use.

The sentence that reads like a guarantee

The domains overview in the Pro help says: “In other words, the field will not accept a value that is not in that domain.” The Domains toolset page is more specific about where that happens: “Validation for coded value domains is accomplished by restricting field values in drop-down lists. Range domains are automatically validated during editing.” Our measurements, below, are consistent with the toolset page, not the overview.

Contingent values are documented the same way. Their restrictions are enforced “in the application whenever a value is placed in a field while editing, such as in the Attribute pane or the Attribute Table view,” and an individual feature edit cannot be completed while it holds an invalid combination. Even the ArcGIS Blog post hedges: with contingent values, an incompatible combination is “less likely to enter the workflow.”

What we wrote, and what got stored

We built a small water pipe class that uses every control the blog names; to keep the test simple, the pipes were stored as points. It had a Material coded-value domain (codes 1 to 3, with descriptions such as PVC and Ductile iron), a Lining coded-value domain, and a Diameter range domain of 2 to 48. A subtype field split the pipes into Main and Lateral, with diameter defaults of 8 and 4 and domains assigned per subtype. A restrictive field group allowed only four material and lining pairs. On top sat three attribute rules: an immediate calculation rule that writes a label, a constraint rule that requires a pressure zone, and a validation rule saying that pipes with a diameter of 24 or more must be ductile iron. For the default-value and ENFORCE_DOMAINS tests we also built smaller classes, among them one with the same Material domain and 2-to-48 Diameter range domain but no subtypes, whose diameter field had a field-level default of 6.

The constraint rule is the blog’s own example: “A water utility uses a constraint rule to require a pressure-zone value whenever a pipe is created or updated. If the value is missing, the edit cannot be saved…”

Then we wrote bad values into the class three ways: an insert cursor, Calculate Field, and Append loading from a staging class that had no constraints of its own. Each ran at its defaults, except Append’s schema_type, which we set to NO_TEST.

None of the first four rows raised an error or a warning. The immediate calculation rule ran on those writes too: it recomputed the label on cursor inserts, on Calculate Field and on Append.

The geoprocessing reference is candid about the defaults. Calculate Field’s enforce_domains parameter defaults to NO_ENFORCE_DOMAINS: “Field domain rules will not be enforced. This is the default.” Append says the same of the target’s field domains. The insert cursor has no such parameter at all; its optional arguments are datum_transformation, explicit and load_only.

Pro does document how to find domain violations after the fact. In the Attributes pane, Select Only Invalid Objects filters the current selection to the features whose values violate the rules of the geodatabase, such as a nullable field, a relationship rule or an attribute domain. The table view can highlight invalid contingent combinations, and the help describes that cue by color only: red for restrictive field groups, yellow for the rest. Both depend on a person going to look. Pro’s editing options also include attribute validation, which governs the domain and null checks in the Attributes pane, and an editor who needs to override domain values can turn it off.

ENFORCE_DOMAINS: the geoprocessing switch, and what it leaves out

Calculate Field, Calculate Fields and Append each take enforce_domains. Set to ENFORCE_DOMAINS, it changes what those tools do with an out-of-domain value, and Append handles it differently from the two calculate tools.

• Calculate Field and Calculate Fields do not write the value. Refused rows get WARNING 001156, for example Failed on input OID 12, could not write value '9' to output field material. Measured on Calculate Field: the refused rows kept their previous values, the valid rows in the same run were calculated, and the tool still succeeded, with a WARNING 000595 naming a .fid file of the records it could not process. The 001156 help page says that when a tool meets many such cases, the message can be listed up to 10 times, with the Object IDs of all of them in a text file named in an accompanying message.
• Append still inserts the record. The documentation says the record is inserted “but the input field will be null,” with a warning identifying the rows, and that when matching fields for update are specified, the target field is not updated. Measured: three staging rows, two of them bad, produced three new rows. In a class whose fields had no default, the refused field received null. In the class without subtypes, the diameter field, whose range domain is 2 to 48 and whose field default is 6, received 0. That is outside its own domain, and neither null nor the default, so do not build anything on the replacement value. For an authoritative load, a kept row with a quietly replaced value looks valid; a constraint rule, which refuses the row, or a check in the loader is the safer choice.
• It does not check subtype codes or contingent values. Measured with ENFORCE_DOMAINS: Calculate Field and Append both stored subtype code 7 and material and lining pairs the restrictive field group forbids, with no warning.
• It does not apply in Append’s feature service mode. That mode, the default of Append’s feature_service_mode parameter, is meant for a target that is a feature service with the Append capability, and the reference says enforce_domains is not supported in it.
• It has no insert cursor equivalent. A script that writes with arcpy.da.InsertCursor has no parameter to ask for one.

So ENFORCE_DOMAINS is a choice the person writing the load makes, call by call. It is not a control the data owner can switch on for everyone who writes to the class.

Subtype defaults and the cursor: omit the field, do not pass None

The InsertCursor reference says: “When a field has a default value, a cursor applies the default value when the field is not specified or is set to None.” We measured both kinds of default.

• A field-level default, on the class without subtypes, behaved as documented. Leaving the field out, or passing None, stored the default of 6. With explicit=True, passing None stored null instead, which is what that argument is documented to do for a nullable field.
• A subtype-level default did not. For a Lateral pipe, whose subtype default diameter is 4, leaving the field out stored 4, but passing None stored null — with explicit set to False or to True.

If a script should pick up subtype defaults, leave those fields out of the cursor’s field list rather than sending None.

The guardrail that held: constraint rules

The constraint rule documentation is short: “If a constraint rule is violated, a user-defined error number and message are returned, and the feature edit is rolled back.” The page describing when rules are evaluated says they run when you edit data in ArcGIS Pro or through a feature service, and does not say whether cursor or geoprocessing writes trigger them. We measured the rules against both. Our pressure-zone rule, which returns error 5001 with the message Pressure zone is required, acted on all three writers:

• The insert cursor raised RuntimeError: Violated attribute constraint rule., naming the rule, the error number and the message, and the row was not stored.
• A Calculate Field run that set the pressure zone to null failed as a whole with ERROR 004111: Attribute Rule Error: Violated attribute constraint rule., and no row changed.
• Append loaded the rows that passed and skipped the one that did not, with WARNING 000594: Input feature 4: Violated attribute constraint rule.. and a WARNING 000595 pointing at a .fid file.

The rule’s message is what an editor sees when an edit is refused, so write it as an instruction a person can act on, as Pressure zone is required does, rather than as a code.

Plan a change window before you add or alter a rule. Creating an attribute rule requires an exclusive lock on the underlying dataset, and so does changing one; rule properties that cannot be modified are read-only, and changing those means deleting the rule and re-creating it. Schedule that work rather than fitting it in while editors are in the data.

Making a constraint rule check the domain

If values reach your data without passing through an editing form, a constraint rule can check the domain for them. Arcade’s Domain() and Subtypes() are Core bundle functions, available since Arcade 1.11, and the Attribute Rule Constraint profile includes the Core bundle. When a feature belongs to a class with subtypes, Domain() returns the domain assigned to the feature’s subtype, so one expression covers per-subtype domains. Each domain expression assumes the domain type it checks: the material rule reads the coded values that only a coded-value domain has, and the diameter rule reads the minimum and maximum that only a range domain has. These are the three expressions we ran. Each is its own rule: paste one expression per rule, never the three together.

Rule dom_material, error 5101: a coded-value check.

var v = $feature.material;
if (IsEmpty(v)) { return true; }
var d = Domain($feature, 'material');
if (IsEmpty(d)) { return true; }
for (var i in d.codedValues) {
  if (d.codedValues[i].code == v) { return true; }
}
return false;

Rule dom_diameter, error 5102: a range check.

var v = $feature.diameter;
if (IsEmpty(v)) { return true; }
var d = Domain($feature, 'diameter');
if (IsEmpty(d)) { return true; }
return v >= d.min && v <= d.max;

Rule dom_ptype, error 5103: a subtype check.

var v = $feature.ptype;
var s = Subtypes($feature);
if (IsEmpty(s)) { return true; }
for (var i in s.subtypes) {
  if (s.subtypes[i].code == v) { return true; }
}
return false;

Each was added as a constraint rule triggered on insert and update, with its own error number and message. For this test the Lateral subtype had a narrower diameter range, 2 to 8, than Main’s 2 to 48. At the tools’ defaults, measured:

• The insert cursor refused material 9, diameter 99, subtype 7, and a Lateral pipe with a diameter of 12, while it stored a Main pipe with a diameter of 12.
• Calculate Field setting material to 9 failed as a whole with ERROR 004111, naming the rule and its message, and changed no rows.
• Append of five rows loaded the one valid row and skipped the other four, each with WARNING 000594.

Know the limits of these rules before you rely on them:

• Nulls pass the domain checks. The material and diameter expressions return true for an empty value, on purpose. If the field must not be empty, change if (IsEmpty(v)) { return true; } to return false. The subtype expression has no such line, so as written it refuses a null subtype code.
• Subtype-level domains need the subtype check. With the material domain assigned only at the subtype level and only the material rule in place, a row with subtype code 7 and material 9 was stored, because an undefined subtype has no domain to look up. The same material on subtype 1 was refused. The Subtypes() rule is what closes that gap.
• Contingent values are not covered. None of the three expressions checks them, and the documentation we read did not include an Arcade function for contingent values.
• Existing violations block later edits. Because the rules fire on update, a row that already breaks one of them fails any update that leaves the bad value in place, unless the update trigger is limited to triggering fields the edit does not touch. The same follows if a code is later removed from a domain these rules read. We did not measure either case; both follow from the documented trigger behavior. Find and fix the existing violations before you add the rules, for example with Select Only Invalid Objects, or set triggering fields on purpose.

A load that succeeds can still have refused rows

When Append skipped a row that broke a constraint rule, it raised no exception. It returned status 4, which the Result reference defines as Succeeded, with Result.maxSeverity of 1 and arcpy.GetMaxSeverity() of 1, which the GetMaxSeverity reference defines as “The tool returned a warning message, but not an error message.” A clean Append returned status 4 with a maximum severity of 0. The runs with ENFORCE_DOMAINS that refused values also finished with a maximum severity of 1. A loader that only catches exceptions reports all of these as clean.

So read Result.maxSeverity or arcpy.GetMaxSeverity() after every tool, and compare rows in with rows added. Two more measured details make the checking harder than it should be:

• Read the message text, not the help page, for 000594. The help page for 000594 lists reasons such as a feature outside the output XY domain or an output that hit its maximum size. It does not list attribute rules, although in our Append runs the message text said Violated attribute constraint rule.
• Do not parse the cursor’s error text. In one long Python session, every refusal read RuntimeError: Field is not editable. [OBJECTID] instead of the rule’s message; runs on fresh geodatabases showed the rule’s message every time. The rows were refused either way, and we did not isolate the cause. Catch RuntimeError around insertRow() and confirm the row is absent.

Inside an edit session

An edit session changes what a refusal costs. The arcpy.da.Editor reference says that when it is used as a with block and an exception occurs, editing is stopped but not saved. Measured: an uncaught constraint refusal inside the block discarded the rows already inserted in that session. Catching the RuntimeError row by row inside the session kept the valid rows. That discard is the rollback our weekly CSV mirror relies on, and it means one row that breaks a constraint rule throws away the whole run there. If your rows are independent of each other, catch the error per row instead, and log and count the refused rows so the load cannot drift silently.

Validation and batch calculation rules run when you evaluate them

Validation rules do not block edits. The Add Attribute Rule reference says existing features are identified with a batch validation process, at a user-defined time, and that “when a rule is violated, an error feature is created.” Our validation rule let 36-inch PVC pipes load without complaint. Evaluate Rules on the file geodatabase then reported 15 rows evaluated and 7 errors identified, stored in GDB_ValidationPointErrors because our test pipes were points. The documentation says the error datasets are created with the first batch calculation or validation rule, and that error features can be reviewed in the Error Inspector during quality assurance. A Validation Status field arrives with the first rule of either type and tracks, row by row, whether calculation or validation is still required and whether the row has errors.

A few documented conditions apply:

• Batch calculation and validation rules are supported only on point, line and polygon feature classes and on tables.
• Every attribute rule needs GlobalIDs on the dataset, and these two types also need editor tracking.
• For file and mobile geodatabases, the geodatabase is the workspace you evaluate.

One measured trap on a mobile geodatabase: an Evaluate Rules run with no extent evaluated only 10 of our 15 rows. The five it skipped lay outside the feature class’s stored extent and stayed marked as needing validation; a second run reported Rows evaluated: 0. The tool reference says that for a file or mobile geodatabase the entire workspace is evaluated, and on the file geodatabase it was. Passing an explicit extent evaluated the missing rows. The same page names a second filter that stacks on top of the extent: if there is a selection in the map, only selected features within the specified extent are evaluated. We did not establish why the stored extent was out of date, so on a mobile geodatabase, compare the evaluated count with the row count.

Enterprise geodatabases, ArcGIS Online and the web

The ArcGIS Blog post carries one note that decides a great deal: “File and mobile geodatabases support all three rule types. For enterprise geodatabases, batch calculation and validation rules require the dataset to be branch versioned and published as a feature service with the Validation enabled.” The documentation confirms the branch-versioning requirement, qualifies the Validation one, and adds the parts that decide a budget:

• Branch versioning comes first. To add either rule type, “the database connection must have Versioning Type set to Branch,” and the operation must be performed as the data owner.
• Publishing with the Validation capability requires branch-versioned data, a branch connection, a connected user who owns the data, and all four error datasets in the map. The capability is enabled on a map image layer that references registered data, with an associated feature layer included, and the publishing account needs the privilege to create content and privileges to publish server-based layers. The capability is optional when you share attribute rules; you need it to evaluate batch calculation and validation rules against the service. None of the Validation pages we read names the ArcGIS GIS Server edition it needs, so settle the server licensing before you budget.
• Evaluating on the service has its own requirements. The evaluate operation on the service’s ValidationServer needs the Edit privilege (features:user:edit) and, from ArcGIS Enterprise 11.2, the ArcGIS Advanced Editing user type extension. Datasets with Data Reviewer-based validation rules also need a Data Reviewer server extension license.
• The Advanced Editing user type extension reaches past evaluation. The ArcGIS Enterprise licensing page says it provides access to attribute rules and branch versioning, along with the utility network, trace network, parcel fabric and topology, through feature layers that reference data in a registered data store. Members must be assigned it to use them. That page names no rule types, and the Pro help ties the extension specifically to evaluating validation and batch calculation rules on web feature layers, from ArcGIS Enterprise 11.2. Neither page says whether a member who only edits a layer whose immediate calculation or constraint rules fire needs it, so budget it for every member who uses attribute rules or branch versioning through those layers, editors included, unless Esri tells you otherwise. The extension is included in the Professional and Professional Plus user types and can be added to user types that can view and edit data, such as Mobile Worker, Contributor and Creator. Those statements come from the ArcGIS Enterprise documentation; the ArcGIS Online user types page we read does not mention the extension. It is a user type extension, not the ArcGIS Pro Advanced license level.
• The web feature layer must reference registered data, not a copy, for its attribute rules to apply. On such a service, “Attribute rules are applied to the back-end datasets and take effect when edits are applied,” and a violated constraint rule returns an error to the client.
• Error layers are shared. If the same dataset is published to several services, the error layers and the validation status are shared for the default version.

ArcGIS Online. The Pro help is direct: “Attribute rules are not transferred when you publish datasets to an ArcGIS Online portal.” We found no other ArcGIS Online route for attribute rules in the documentation we read, and we did not publish to test it. If you load data into hosted feature layers published from Pro, plan on the rules not being there, and put the checks in the loader. For a team with ArcGIS Online and ArcGIS Pro but no ArcGIS Enterprise, the documentation offers two places the rules run. One is Pro editing a file or mobile geodatabase, which supports all three rule types. The other is an app built with a Native SDK editing a stand-alone geodatabase exported from Pro and side-loaded onto the device, where only constraint and immediate calculation rules run (see the next list). Budget for that route: a Native app needs a production license, and editing a stand-alone mobile geodatabase created with ArcGIS Pro sits at the Basic level, not Lite. The documented way to download rules into a sync-enabled geodatabase needs ArcGIS Enterprise 11.4 or later feature services. Neither route puts a rule on data hosted in ArcGIS Online. Domains are another matter: they are visible on a hosted layer’s fields, and we showed how to read them in the data dictionary post. One exception covers the schema this article builds: if you publish a hosted feature layer from ArcGIS Pro that contains subtypes with associated domains on other fields, you cannot view or edit those domains in ArcGIS Online.

What a service does with a bad domain value is not documented where we looked. The Apply Edits reference we read does not mention domains or contingent values, and we did not test one. Whether a feature service rejects an out-of-domain value, an undefined subtype code or a forbidden combination is, as far as this post goes, unknown.

Which clients evaluate the rules

• ArcGIS Pro evaluates immediate calculation and constraint rules locally, before the edit is sent to the data source, unless the rule’s Exclude from application evaluation option is on.
• Apps built with the ArcGIS Maps SDKs for Native Apps (.NET, Kotlin, Swift, Qt and Flutter) support constraint and immediate calculation rules only; the guides we read in September 2026 say batch calculation and validation rules are not currently supported. The supported rules are evaluated locally when that option is off, with no extra code. The guides list three places this works: service feature tables from a web map or a service geodatabase; sync-enabled mobile geodatabases, where downloading the rules needs ArcGIS Enterprise 11.4 or later feature services; and geodatabases exported from ArcGIS Pro and side-loaded onto the device. On a side-loaded geodatabase, the supported rules are evaluated whatever the option says. Rules are not supported on a service feature table created with one of its constructors. We did not build a Native app to test any of this.
• Web apps built with the ArcGIS Maps SDK for JavaScript do not evaluate attribute rules in the browser. The Arcade attribute rule profiles list ArcGIS Pro, ArcGIS Enterprise and the Native SDKs as the products that implement them, and not the JavaScript SDK; for a JavaScript app, the rules run at the service. The SDK can read a layer’s subtypes, and its FeatureFormViewModel has offered a client-side validateContingencyConstraints() since 4.23. At 5.0, though, the FeatureForm widget that uses it is deprecated, and its replacement, the arcgis-feature-form component, lists no contingency method.

Exclude from application evaluation is not a way around a rule. It moves the evaluation from the client to the data source, where the rule still runs. It must be on for an immediate calculation rule whose expression returns certain attribute rule dictionary keywords, uses sequences, or uses the field value in the calculation, and it does not apply to validation or batch calculation rules.

What it costs, and who can do it

On Pro Basic, from a web feature layer, or over a database connection as anyone other than the data owner, the Attribute Rules view is read-only. The table speaks in license levels, so check which ArcGIS Pro license level each person has before you plan rule work.

Data Reviewer is separately licensed. The ArcGIS Blog post suggests starting with Data Reviewer’s Run Data Checks tool and never says it is separately licensed. In ArcGIS Pro, Data Reviewer is available for all license levels as an add-on to a Named User, Single Use or Concurrent Use license. Creating, modifying or evaluating Data Reviewer-based attribute rules in a file or mobile geodatabase needs a Data Reviewer license and Pro Standard or Advanced, and the Ready to Use Rules gallery also needs a Data Reviewer license. In ArcGIS Enterprise, a web feature layer with the Validation capability over datasets with Data Reviewer-based rules needs the Data Reviewer server extension, a CPU-based license for each GIS Server federated with the organization, available for the Standard and Advanced editions of ArcGIS GIS Server. Check your own entitlement before you plan on it.

Credits. We found no ArcGIS Online credit cost for domains, subtypes, contingent values, attribute rules, Evaluate Rules or error datasets in any page we read. The costs are licenses and platform. Batch calculation and validation rules on enterprise data need ArcGIS Enterprise, a branch-versioned enterprise geodatabase and the Advanced Editing user type extension. From ArcGIS Enterprise 11.2, every member who evaluates them needs that extension, and the ArcGIS Enterprise licensing page says members who use attribute rules or branch versioning through web feature layers must be assigned it.

Compatibility. Adding attribute rules raises the dataset’s minimum client to ArcGIS Pro 2.1, so it is no longer available in ArcMap. Contingent values make a dataset incompatible with ArcMap and with releases before ArcGIS Pro 2.3 and ArcGIS Enterprise 10.7.x. Copy and paste and XML workspace documents carry attribute rules; Feature Class To Feature Class and Table To Table do not.

Who the guardrails do not stop

In an enterprise geodatabase, attribute rules are added as the data owner, and only the domain’s owner or the geodatabase administrator can change a domain. Rules can also be switched off. Esri documents disabling attribute rules on a dataset, from the Attribute Rules view or with the Disable Attribute Rules and Enable Attribute Rules tools, and gives the reason: it “can improve performance for bulk data loads.” On our file and mobile geodatabases it works: we disabled the pressure-zone rule, appended a row with no pressure zone, re-enabled the rule, and the row stayed. The two tools need Pro Standard or Advanced. For a file or mobile geodatabase, that license level is the only condition the tool pages put on running them; they name no data owner or other role there.

Two consequences follow. First, immediate rules add work to every edit that triggers them, which is why the documentation suggests switching them off for bulk loads; we did not time it. The documentation names other levers when evaluation cost becomes the problem. Order the cheap constraint rules first, so evaluation fails early rather than after the complex ones, and migrate the error tables, which default to 32-bit ObjectIDs, once the values pass that range. Large service evaluations already run asynchronously through the ValidationTools geoprocessing service by default, an option that needs a feature service with the Validation capability. While the rules are off, they are off for the dataset, so every writer is unguarded by those rules until they are back on. A load that disables them has to do its own checking, or evaluate a validation rule afterward, and it has to re-enable them in a finally block so a failed run does not leave them off. Second, every writer we tested was ArcGIS software, and the documentation describes rules running in ArcGIS Pro, feature services and Native apps. It does not say rules run for writes made outside ArcGIS, so test any such writer before you count on a rule. A constraint rule guards the data against writers that go through ArcGIS, not against whoever can disable it. The control designed to review data that is already stored is a validation rule, which identifies existing features at a time you choose.

Before you rely on a guardrail

1. List every writer, not just the editors. The editing form is only one of the ways values arrive: scripts, geoprocessing tools, scheduled loads and services are others. Note which of them are not ArcGIS software, and test any such writer before you count on a rule.
2. Put the values your ArcGIS writers must not store in constraint rules, and remember that whoever can disable a rule can load what it would refuse. If loads bypass the editing form, add Domain() and Subtypes() checks, decide on purpose whether an empty value passes, and fix existing violations before the rules go on. If a large load switches the rules off for speed, the load does the checking and turns them back on even when it fails.
3. Decide on ENFORCE_DOMAINS call by call. Append keeps the row and replaces the refused value: with null, or, measured, with 0 on a range field that has a default, and that 0 can itself be out of range. For rows it updates through matching fields, it leaves the target field unchanged instead. The parameter checks neither subtype codes nor contingent values.
4. Leave fields out of an insert cursor when you want their subtype defaults.
5. Check the maximum severity after every tool, and compare row counts: when Append skips a row, or a tool run with ENFORCE_DOMAINS refuses a value, the result is a warning, not an exception. Counts alone miss an ENFORCE_DOMAINS Append, which keeps every row.
6. Inside an edit session, catch refusals per row if one bad row should not discard the rest.
7. Evaluate validation rules on a schedule, and on a mobile geodatabase compare the evaluated count with the row count.
8. Know the platform. Rules are not transferred when you publish from Pro to ArcGIS Online, so checks for data you load into hosted layers live in the loader. In an enterprise geodatabase, batch calculation and validation rules need branch versioning; the Validation capability is optional when you share them and required to evaluate them against the service. Budget the Advanced Editing user type extension for every member who uses attribute rules through web feature layers; from ArcGIS Enterprise 11.2 it is required to evaluate batch calculation and validation rules on them. Native apps run only the constraint and immediate calculation rules.
9. Check licensing. Adding or disabling rules needs Pro Standard or Advanced, so check which ArcGIS Pro license level each person has, and Data Reviewer is a separate license.

The controls are not interchangeable. Domains and contingent values shape what an editor is offered, and subtypes supply categories, defaults and per-subtype domains. Immediate calculation rules fill values and constraint rules refuse the edit, whether it came from an editing form or, in our Pro 3.7.1 file and mobile geodatabase tests, from a cursor or a geoprocessing tool. Batch calculation rules calculate and validation rules report, when you evaluate them. Choose among them by listing who writes the data, not by what the editing form shows.

References

• ArcGIS Blog: Building Better Data Management Workflows in ArcGIS Pro (the September 16, 2026 post this article tests, including its enterprise note)
• ArcGIS Pro: Introduction to attribute domains (coded and range domains, descriptions, and domain ownership in enterprise geodatabases)
• ArcGIS Pro: An overview of the Domains toolset (where coded-value and range domains are validated)
• ArcGIS Pro: Create and manage contingent values (enforcement in the application, restrictive field groups, and retired values)
• ArcGIS Pro: Evaluate attribute rules (immediate and deferred evaluation, Exclude from application evaluation, and the Advanced Editing extension)
• ArcGIS Pro: Constraint attribute rules (error numbers, messages and rollback)
• ArcGIS Pro: Add Attribute Rule (rule types, branch connections, licensing, and the ArcMap cutoff)
• ArcGIS Pro: Create and manage attribute rules (disabling rules to improve performance for bulk data loads, and the read-only Attribute Rules view)
• ArcGIS Pro: Disable Attribute Rules (switching rules off, and the license level it needs)
• ArcGIS Pro: Calculate Field (enforce_domains and its default)
• ArcGIS Pro: Append (enforce_domains, null in place of a refused value, matching fields, and feature service mode)
• ArcPy: InsertCursor (default values, explicit, and the cursor’s parameters)
• ArcGIS Pro: Tool message 001156 (values not written under Enforce Domains, and the 10-message limit)
• ArcPy: Result (status 4 as Succeeded, and the maximum severity of the messages)
• ArcPy: GetMaxSeverity (severity 1 means warnings but no error)
• Arcade: Feature functions (Domain() and Subtypes(), their bundle and their return values)
• Arcade: Attribute Rule Constraint profile (function bundles, return types, and the products that implement the profile)
• ArcGIS Pro: Share datasets with attribute rules (the Validation capability, registered data, and publishing to ArcGIS Online)
• ArcGIS Pro: Additional layers and capabilities (what the Validation capability requires of the map image layer and its data)
• ArcGIS REST API: Evaluate (Validation Server) (the privilege and licenses needed to evaluate rules on a service)
• ArcGIS Enterprise: Introduction to licensing user type extensions (what the Advanced Editing extension covers and which user types include it)
• ArcGIS Maps SDK for .NET: Attribute rules (the rule types Native apps support, and where they evaluate them locally)
• ArcGIS Maps SDK for JavaScript: FeatureFormViewModel (the client-side contingent value check)
• ArcGIS Pro: Frequently asked questions (the ArcGIS Data Reviewer FAQ: Data Reviewer as an add-on license and its server extension)