Managing Feature Classes and Services for Offline Use in Collector

[CharliePhilbrick1]

I am trying to help my organization reach a decision about how best to set up our enterprise data for offline editing in Collector. We've been going back and forth between the merits of using feature classes with archiving enabled or ones that are versioned. I'll omit details of our current configuration and justifications for now. If anyone is curious about that or more information is needed to provide me with guidance, I'm happy to pass along relevant details.

My principle question is this: what is the wisdom of enabling archiving on versioned data? I'm imagining a kind of hybrid scenario where versioning is turned on so that no one is directly editing our default production data AND archiving is also enabled so that I'm not spending all my time managing replicas and versions.

Based on my own experience as well as the two esri help articles linked below, I think I understand the challenges and benefits of pursuing either an archiving-only or versioning-only approach. Our DB administrator has pretty much ruled out the archiving-only approach out of concern for the sanctity of our production data. Versioning-only will certainly work, but I am daunted by the prospect of dealing with all the versions that increased offline use of Collector within our organization is going to cause. I suspect that the reconciliation processes could be automated through scripting such that we would have a kind of last-edit-in-wins scenario, but doesn't Archiving provide that experience with the added advantage of being able to roll the clock back if need be?

I'd love some guidance based on the particulars I laid out above, but I'd be happy if someone could just point me in the direction of some documentation about what to expect from what I'm calling a 'Varchiving" environment.

Thanks Much!

Enabling archiving—ArcGIS Help | ArcGIS Desktop - of particular note the subsection 'Enabling archiving on versioned data'

Prepare data for offline use—Documentation | ArcGIS Enterprise - 

[MarkLund]

Hi Charlie,

We use versioning along with database replication to handle this problem.  Our set up is like this:  One main SDE database that contains the majority of our GIS Data let's call this DATA1, we have a couple of smaller SDE database's that contain more unique data that's not shared by the majority of users, for example Tree Inventory data, let's call that one TREE1.  We have field staff that want to use Collector to edit stuff from DATA1 and we have different field staff that want to edit stuff from TREE1 along with office staff editing from both databases in Arcmap.  We set up Two-Way Replica's on both databases only to be used for the Collector environment.  So there is a two-way replica to a new SDE database called DATA1REP, in here is where all of the Collector versions can pile up and not mess up our DATA1 compress process.  We have nightly scripts that rec/post each database and then Sync the replicas after which we need to rec/post the databases again so all the edits make it to all versions from both sides of the replica.  It sounds a little complicated but we've had it in place for a couple of years now and haven't had any issues.  Anytime staff needs a new Collector application we'll spin up a new database, replicate the needed data to it and then create the collector app from there.  I'm sure there are other ways to handle this, hope this helps.

Mark