Latest Contributions by JayCary

Hi @KimberlyGarbade Thanks-much for providing the details on your deployment. This sounds similar to a bug that the team found that was specific to errors created when using the Query Attributes check in a services-based workflow (it could not be reproduced in a FGDB). The phase and status columns of the error features were not being updated once the error condition was resolved.  The bug was fixed in the ArcGIS Pro 2.9/ArcGIS Enterprise 10.9.1 release. ... View more

@KimberlyGarbadeThe phase and status values should be automatically updated to Verified/Acceptable once the error condition no longer exists. What version of ArcGIS Pro/ArcGIS Enterprise (for services-based workflow) are you using? For troubleshooting purposes, I would suggest disabling (or deleting) the Arcade-based validation rule that tests for the same error condition and then re-run the evaluation. Before evaluating the feature, please verify that the feature's VALIDATIONSTATUS field value is either 2 (No calculation required, validation required, no error) or 6 (Calculation required, validation required, no error). Otherwise, the feature is skipped during evaluation. Thanks in advance for the feedback ... View more

@KimberlyGarbade  Can you verify the current Phase/Status information of these error results? You can add the phase/status columns to the Error Inspector by doing the following: From the Error Inspector, click the options button and click Show Status. The Phase and Status columns appear in column position 1 and 2. Reviewer-created errors have a slightly different life cycle than those created using Arcade. Thanks for the feedback! ... View more

Thanks for the feedback When creating additional feedback during QC - We run batch jobs as part of the QC process, but also create additional records manually for the analyst to review. Sometimes we make mistakes and need to edit or remove manual records. Support for creation/management of error features identified through semi-automated workflows (such as visual review) are on the product roadmap. It is envisioned that error features created in these workflows will require manual update to their life cycle fields (Correction technician/notes, Verification technician/notes). Sometimes analysts make mistakes when working through a list of errors and would like to edit the Status or Correction Notes. If they can’t edit, they may delete a record, rerun the batch, and update the Status/Correction Notes again. In validation attribute rule workflows, error features created using Data Reviewer checks are automatically updated to reflect their current phase and status. For example, once the error condition has been addressed the next time the feature is evaluated the related error feature(s) are automatically updated. You can see this behavior in action in this video (starting @ 12:30) We have a process that writes exceptions from a given session to an exception table (so they won’t pop-up in every job), but we don’t want all exceptions to be written. So in that case we delete those records prior to running the process. This may not be an issue in validation attribute rule workflows. The error management "overhead" is significantly reduced since the error tables are system managed and maintain a 1:1 relationship between rule errors and features. This eliminates the need to manually manage rule exceptions and prevents the creation of duplicate errors. That said, in branch-versioned environments editors will need to reconcile/post errors to the default version to ensure that errors which are marked as exceptions are available to other named versions. And finally, sometimes when testing checks, we write results to a table since it can be easier to work with them. If you get incorrect results, it’s easier to delete them than getting stuck with a table full of stuff you don’t want or having multiple reviewer sessions. This also may not be an issue in validation attribute rule workflows. When a validation rule is deleted all corresponding errors are automatically removed from the error tables. ... View more

It sounds as if you are trying to use a Reviewer Batch Job (.rbj) from Workflow Manager (Classic?) to validate features shared through a branch-versioned feature service. If so, then the problem you're encountering may be due to the fact that Batch Job-based validation only supports traditional and non-versioned workspaces. For branch-versioned services, the recommended workflow is to use Data Reviewer's checks that have been integrated into Attribute rule workflows and the Validation service.  Workflow Manager 10.9.1 includes a new step (Evaluate Data Quality) that integrates this service into a job.   The Q2 2022 release of ArcGIS Pro will include an automated method for converting Reviewer Batch Jobs to Attribute rule CSV. ... View more

Here is another resource for getting started with Data Reviewer in ArcGIS Pro: https://pro.arcgis.com/en/pro-app/latest/help/data/validating-data/get-started-with-data-reviewer.htm ... View more

Hi @lpenuelac, I agree that there can be a significant amount of time invested in the creation of Reviewer Batch Jobs in ArcMap. In the next ArcGIS Pro release, there are plans to provide a capability to convert a Reviewer Batch Job file (.rbj) into a series of comma-separated files (.csv) suitable for use with Attribute rules. The resulting .csv files can then be imported as Attribute rules using either the Import Attribute Rules geoprocessing tool or the Import Rules command in ArcGIS Pro. ... View more

A Data Reviewer extension license is required for the following Attribute rule workflows: Create/modify Data Reviewer-based constraint or validation Attribute rule (desktop license) Evaluate feature/row with Data Reviewer-based validation Attribute rule File/mobile geodatabase (desktop license) Evaluate REST operation (server license) Update lifecycle status of error result File/mobile geodatabase (desktop license) Evaluate REST operation (server license) ... View more