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.
