ArcGIS Pro Reports

Question

Hello,

We are trying to generate a report in ArcGIS Pro that uses our parcel layer with a relate or join to a standalone table that contains our revisions for tax map changes. I was successful in creating the report template using fields from the standalone table after doing a join to the parcel layer. However, it did not occur to us that the fields cannot be edited in the standalone table after doing so. In order for this to work, we need to be able to edit the revision and be able to add a record to the revision table.

The next thing we are trying is doing a relate instead of a join. However, I can't seem to get this to work either. Attached is an example of what we want our report to look like.

Does anybody have any ideas on what to try next to get this to work properly? Or a workaround or something that mimics what we are trying to do?

Thank you!

-Warren County NY GIS

12.10.2024_4.pdf

RTPL_AU · Answer

@AmandaBeck 
With all the Dynamic Text options, Tables, etc now possible in Map Series, I've found scenarios where it is easier to mimic a report using a map series than it is to get something to work in Reports. I've been stuck with date formatting, number field rounding, relationships/joins, etc. that were no-brainers in a Layout.

VenkataKondepati · Answer

What you’ve run into is expected:

Joins in ArcGIS are read-only for the non-origin table. Once you join your revisions table to parcels, you can display those fields in a report, but you can’t edit or add records through the join.

Relates don’t “carry fields” into the layer—they just define a relationship so you can query related records, but you won’t see those fields show up directly in your report template.

Options / Workarounds

Use Relationship Classes

* In your geodatabase, create a relationship class between parcels and the revisions table (parcel ID ↔ revision parcel ID).
* Reports in ArcGIS Pro can then access related records through the relationship, and you can still edit or add rows directly in the revisions table.
* This is the cleanest long-term solution because it formalizes the “1 parcel ↔ many revisions” relationship.

Build the Report Off the Table, Not the Join

* Instead of basing the report on the joined layer, use the revisions table as the report source.
* You can then pull parcel attributes into the report via the relate/relationship class.

Use a Query Layer or View (Database-side)

* If your data is in an enterprise geodatabase (SDE), you could create a database view that joins parcels ↔ revisions.
* That view can be added to ArcGIS Pro, reported on, and your original revisions table remains editable.

“Two-step report” approach

In some cases, folks design the report using parcels as the main source, then insert a Related Report section that lists all revisions for each parcel (pulled via relationship).

If you need ongoing editing in the revisions table and a working report, the best route is:

Create a relationship class in the geodatabase.

Build the report to use that relationship (main section = parcel, related section = revisions).

Users can continue to add/edit revision records in the standalone table—no need to break the workflow.

Don’t use a join here—set up a relationship class so you can edit revisions and still generate the report you need.