Managing Data Outside of Parcel Fabric?

[ClayNorris]

I'm wondering what the best method is for determining which data layers should be part of the Parcel Fabric. We have some layers that we don't necessarily care about tracking lineage, but we want to take advantage of topology. An example of this could be school districts or council districts. We want this to line up topologically with other layers in parcel fabric, but does it necessarily need to be included? What is best practice for deciding which layers to build into it? Lean and mean, or all encompassing? Thanks!

[AndrewWallick]

I'm also very interested in this. We have tons of layers that need to align to parcels, but so far it's mostly been a manual effort.

[AmirBar-Maor · Accepted solution]

The parcel fabric was designed to support Administrative Parcels (like the districts mentioned above).
When creating a new parcel type you have the option to make it Administrative.

This makes sense when the 'parcels' (admin boundaries) coincide with the parcel layer. For performance reasons, it would be good to try and consolidate the number of 'parcel types'. This approach assumes that the datasets align to each other to start with. If they don't you have to start with a conflation project.

Another option, which is more labor-intensive and requires good 'bookkeeping', is available for those using ArcGIS Enterprise: use the geoprocessing Generate Parcel Fabric Links between 2 moments in time, and then apply the generated links and anchor points using the Rubbersheet Features tool to related data.

[NateArnold]

Is there a way to have administrative parcels be separated out by ownership/edit permissions from the core parcel types?  One department edits the tax map, but there are other departments who have their own purview over polygons that need to align with the tax parcels etc. 

[AmirBar-Maor]

The reason you would want the administrative parcels in the same parcel fabric is to keep the datasets coincide with each other. 

When a point moves, you want it to update all the parcel features it is shared with, which means one group will effectively update parcels of another group. And that is something we want.

So how do we prevent people from one group create or update parcels of another group? 

The answer depends on the level of trust between the groups. Here are a few solutions to consider based on the trust level:

1. Trustworthy - prevent accidental edits: each group works with a map that does not contain the feature templates of the features that are maintained by the other group. So they cannnot create parcel types they are not supposed to create.
2. Less Trust - you can create groups on your portal and associate users to each group. Arcade allows you to find which group a user belongs to:

// find which groups a portal user belongs to. Returns an array.
var myPortal = Portal("https://galileo.esri.com/portal/");
var currentUser = getuser(myPortal);
return currentUser.groups​

You can use Arcade to create a validation rule that checks if a parcel from a given type was created by a user from the wrong group. This can also be a constraint rule. Make sure to use the triggering fields and allow parcels from the wrong type to have their geometry updated by the other group (e.g. - when a point is moved it should update all parcel types). If you want to get fancy you can also consider user the Arcade method $OriginalFeature to allow geometry updates to pass and prevent attribute updates.

3. No Trust - with this method you can create 2 parcel fabrics, one for each group and use the geoprocessing Import Parcel Fabric Points to TRY and keep them in sync. It will never be perfect, but if you start from the same parcel fabric, then delete the parcel type that is not needed for each group, you should have all the common points between the parcel types.  This approach is likely to be used between 2 organizations that have 2 different networks that cannot be shared.

I hope this helps

Amir