Attribute Rules in ArcGIS Pro: Automate Data Quality in 5 Steps

What Attribute Rules Actually Do

Attribute rules are Arcade expressions stored directly in your geodatabase that execute automatically when features are created, updated, or deleted. They run at the database level — not in the application — which means every editing client respects them: ArcGIS Pro, web apps, Field Maps, the ArcGIS API for Python, even direct REST API edits.

This is the critical distinction from application-level validation. If you build validation logic in a web app, someone editing in Pro bypasses it. If you build it in Pro, web editors bypass it. Attribute rules close that gap permanently.

Here are five steps to get attribute rules working in your geodatabase.

Step 1: Identify Your Data Quality Pain Points

Before writing any Arcade, catalog the data quality issues that actually cost your organization time:

• Missing required fields: Editors leave STATUS, CONDITION, or INSTALL_DATE blank. Downstream reports and dashboards show null values or wrong totals.
• Invalid field values: Free-text entries in fields that should be domain-constrained. “Residential” vs “residential” vs “Res” vs “R” in a ZONING field.
• Inconsistent derived fields: FULL_ADDRESS should be STREET_NUM + ” ” + STREET_NAME + ” ” + STREET_TYPE, but 30% of records have mismatches because someone typed the full address manually.
• Cross-field logic errors: A pipe with MATERIAL = “PVC” and DIAMETER = 48 inches — PVC does not come in 48-inch diameters.
• Spatial inconsistencies: A fire hydrant feature that falls outside any water pressure zone polygon.

Rank these by business impact. The issue that generates the most rework, the most complaints from downstream consumers, or the most risk gets automated first.

Step 2: Choose the Right Rule Type

Attribute rules come in three types, and choosing the wrong one creates friction:

Calculation Rules — Auto-Populate Fields

Fires on insert, update, or delete. Writes a value to one or more fields automatically. The editor does not interact with the rule — it just happens.

Use for:

• Concatenating address components into a FULL_ADDRESS field
• Auto-stamping LAST_EDITED_BY and LAST_EDITED_DATE (without relying on editor tracking, which can be disabled)
• Calculating LENGTH or AREA from geometry
• Assigning a sequential ID based on existing records
• Copying attributes from an intersecting polygon (e.g., assign ZONE to a new point based on its location)

Example — auto-populate FULL_ADDRESS on insert and update:

// Calculation rule — triggers on Insert, Update
// Field: FULL_ADDRESS
var num = $feature.STREET_NUM;
var name = $feature.STREET_NAME;
var type = $feature.STREET_TYPE;
var suffix = $feature.STREET_SUFFIX;

var parts = [num, name, type];
if (!IsEmpty(suffix)) {
    Push(parts, suffix);
}
return Concatenate(parts, " ");

Constraint Rules — Block Invalid Edits

Evaluates a condition and rejects the edit if the condition returns false. The editor sees an error message and must fix the data before the edit commits.

Use for:

• Enforcing required fields (not-null checks)
• Cross-field validation (material + diameter combinations)
• Range checks (pipe pressure rating between 50 and 300 PSI)
• Spatial containment (feature must fall within a specific boundary)

Example — prevent invalid material/diameter combinations:

// Constraint rule — triggers on Insert, Update
// Returns true (valid) or false (rejected)
var material = $feature.MATERIAL;
var diameter = $feature.DIAMETER;

if (material == "PVC" && diameter > 36) {
    return {
        "result": false,
        "errorMessage": "PVC pipe cannot exceed 36-inch diameter. Use DI or Steel for larger sizes."
    };
}
return true;

Validation Rules — Flag Existing Issues

Runs as a batch operation against existing data. Does not block edits — instead, writes results to an error table that you review. Think of it as automated QA.

Use for:

• Finding legacy data that violates new business rules
• Detecting spatial anomalies (features outside expected areas)
• Pre-migration data assessment
• Periodic quality audits triggered manually or on schedule

Step 3: Write and Test the Arcade Expression

Attribute rule Arcade has access to functions not available in other Arcade contexts:

• $feature — the feature being edited (current state)
• $originalFeature — the feature before the current edit (for update triggers only)
• $editContext — metadata about the edit (edit date, editor name)
• FeatureSetByName() — query other feature classes in the same geodatabase
• NextSequenceValue() — generate sequential IDs from a database sequence

Write your expression in the ArcGIS Pro Attribute Rule view (Feature Class > Design tab > Attribute Rules). The built-in expression editor provides syntax validation and auto-complete.

Testing approach:

1. Create the rule on a test copy of your feature class. Never write rules directly against production data without testing.
2. Test the happy path — valid edits should succeed without errors.
3. Test the failure path — invalid edits should be blocked (constraint) or flagged (validation).
4. Test edge cases: null values, empty strings, special characters, very long strings, and geometry-only edits (no attribute changes).
5. Test through every editing client your team uses: Pro, web map editor, Field Maps, Python API.

Step 4: Deploy to Production

Attribute rules are stored as part of the geodatabase schema, which means deployment follows your existing schema change process:

For Enterprise Geodatabases

1. Create rules in a development/test geodatabase.
2. Export rules using arcpy.ExportAttributeRules_management() to a CSV file.
3. Import to production using arcpy.ImportAttributeRules_management().
4. Rules take effect immediately — no service restart required for branch-versioned services. Traditional versioned services may need a stop/start cycle.

For ArcGIS Online Hosted Feature Layers

1. Rules are added through ArcGIS Pro connected to the hosted feature layer.
2. Open the feature layer in Pro, navigate to the Attribute Rules view, and add rules directly.
3. Rules propagate to all web maps and apps consuming that feature layer immediately.

Version Control Your Rules

Arcade expressions are just text. Store them in your code repository alongside your other GIS automation scripts. When you export rules to CSV, commit that CSV to version control. This gives you an audit trail of rule changes and the ability to roll back.

Step 5: Monitor and Iterate

After deployment, watch for three things:

Editor Friction

Constraint rules can frustrate editors if the error messages are unclear or if the rules are too restrictive. Monitor help desk tickets and direct feedback for the first 2-4 weeks after deployment. Adjust error messages to be specific and actionable — “Invalid entry” tells the editor nothing; “PVC pipe cannot exceed 36-inch diameter. Use DI or Steel for larger sizes.” tells them exactly what to fix.

Performance Impact

Rules that query other feature classes via FeatureSetByName() add latency to every edit. A point-in-polygon lookup against a 50,000-polygon layer might add 200-500ms per edit. For interactive editing, keep the total rule execution time under 1 second. For batch operations, calculate the aggregate impact.

Performance tips:

• Filter the FeatureSet with a Filter() call before iterating — do not scan the entire layer.
• Use spatial filters (Intersects()) to limit the query extent.
• Cache expensive lookups in variables — do not call FeatureSetByName() multiple times for the same layer.

Rule Conflicts

Multiple calculation rules on the same field execute in the order they were created. If Rule A sets STATUS to “Active” and Rule B conditionally sets STATUS to “Pending,” the execution order matters. Document your rules’ dependencies and test combinations.

Real-World Implementation: Water Utility Hydrant Inspections

A municipal water utility implemented the following attribute rules on their fire hydrant feature class:

1. Calculation — auto-assign PRESSURE_ZONE: On insert, query the PressureZone polygon layer and populate the ZONE_ID field based on hydrant location. Eliminated manual zone assignment errors (previously 12% error rate).
2. Constraint — enforce inspection dates: NEXT_INSPECTION_DATE must be within 365 days of LAST_INSPECTION_DATE. Blocked backdating and unreasonable future dates.
3. Constraint — require flow test results: When INSPECTION_STATUS is set to “Complete,” STATIC_PRESSURE, RESIDUAL_PRESSURE, and FLOW_GPM must all be non-null.
4. Calculation — auto-calculate flow rating: Based on FLOW_GPM, assign FLOW_RATING as “A” (>1,500 GPM), “B” (1,000-1,500), “C” (500-1,000), or “D” (<500).
5. Validation — detect orphaned hydrants: Batch rule flags hydrants not within 50 feet of a water main feature. Run monthly to catch digitizing errors.

Result: Data QA review dropped from 8 hours/week to 3 hours/week. The 5 hours saved went directly back into fieldwork.

Frequently Asked Questions

Can attribute rules work with versioned data?

Yes. Attribute rules work with both branch versioning and non-versioned data. For traditional (SDE) versioning, rules execute when edits are made to a version, and they evaluate again during reconcile/post if conflicts are detected. Branch versioning handles rule evaluation at the service level.

Do attribute rules work offline in Field Maps?

Calculation rules execute offline. Constraint rules also execute offline and block invalid edits on the device. Validation rules do not run offline — they are batch operations. When the field worker syncs, rules that depend on server-side FeatureSet queries (like point-in-polygon lookups against a layer not in the offline map) are deferred until sync, when they execute server-side.

What is the performance impact of attribute rules on large batch edits?

Each rule adds execution time per feature edited. For a simple field calculation (no FeatureSet queries), expect 1-5ms per feature. For rules with FeatureSet lookups, 50-500ms per feature depending on the query complexity. A batch update of 10,000 features with a FeatureSet-based rule could add 8-80 minutes of processing time. For large batches, consider disabling rules temporarily, running the batch, then running validation rules to catch issues.

Can I use attribute rules to enforce topology or geometric constraints?

Attribute rules can evaluate geometry (length, area, intersections with other features) using Arcade geometry functions. However, they are not a replacement for geodatabase topology rules. Use attribute rules for attribute-level and simple spatial validation; use topology for complex geometric relationships (must not overlap, must be covered by, boundary must be covered by).

Need help implementing attribute rules in your geodatabase? Book a discovery call with GeoLever — we specialize in data quality automation for Esri environments.