Common challenges organisations face when managing ArcGIS in-house


Getting the best out of your maps depends on your staff and customers being able to access and use them easily.  Esri’s ArcGIS Platform makes creating and sharing maps fast and easy, meaning your team and your clients have the freedom to develop and adapt their own solutions to meet their specific needs.  

One side effect of this flexibility is a blurring of the line between users and administrators, which makes fertile ground for innovation, but can also make it difficult to maintain order and efficiency across users, groups, and content.  In our work with organisations that have been managing their own platforms for some time, we are often approached to solve some of the following common issues.

Are our users using the right map?

As businesses create their own maps, and staff start to explore their potential, it can become harder for users to find the exact map they are looking for.  Some of our customers have over 100 maps in their ArcGIS Platform, some of them with subtle but important differences depending on why they were made and who is expected to use them.  This can lead to frustration as locating the exact map you need becomes more complicated.

Is this map fit for purpose?

During an audit of one of our customers’ ArcGIS Platform we discovered that one of their maps had been used five times more than any of the others.  This particular map had been made for the customer’s property acquisition team, but came to be used across the business because it contained information about roads that was missing on other maps.  Unfortunately this information was incorrect – the original data source was not authoritative, meaning that staff were making poor decisions on incomplete and inaccurate data.

Where did this map come from?

One of our customers manages a lot of maps in an ArcGIS Platform that has been live for several years.  Over time as staff have left and been replaced, users have begun to ask questions about maps which newer staff members can’t answer.  Without the ability to consult the original creator of a specific map, it can be hard to learn why the map was created, where the content was sourced from, when it was last updated or most importantly how they can continue to support the users that need this map.


What will happen if we make a change to a map’s content?

In an ArcGIS platform, a map’s content is made up of layers – think of the layers of a cake or a sandwich – so all the roads on a given map might be in one layer, with all the buildings in another.  This means if you want to transfer information about buildings from one map to another you can do so without having to create and maintain a whole new buildings layer. This is a powerful tool when used properly, but can lead to unintended consequences – for example, one of our customers created a layer showing the location of cycling tracks which is used in a number of other maps.  A user made a change to the layer to make it display differently on their map, but in the process they broke all the other maps it was included in.


How do we prioritise which maps we maintain and what is the test release process?

When your platform reaches a certain level of complexity, it can become difficult to know which maps are being used, and by whom; and to identify how critical any given map is to your organisation. One of our customers made an update to a map which broke a number of other maps across their business.  A staff member was quick to identify the problem with a map they were using, bringing it to the attention of the administrator immediately and pushing for the map to be fixed. Unfortunately this particular map was only used by a small number of users – and while it was being fixed, the administrator didn’t notice that a business-critical app had also been affected, preventing many staff from doing their job.  As a result a large number of staff were frustrated and started disengaging from using the map.


These seemingly disparate problems can all be traced back to one issue: Role Based Access Control.  


Why focus on Role Based Access Control?

At first glance, Role Based Access Control is about assigning users and staff different levels of access to software.  But this is not as simple as it may sound. User numbers for NZ mapping software solutions often exceed tens of thousands, and the apps are often widely available in the public domain.  At this level of complexity it is vitally important that users understand what their responsibilities are, and are provided with an appropriate level of training and support materials.  Your policy can’t be static – it needs to evolve with new administrative users being trained and assigned as the user base grows.


This is especially true of ArcGIS platforms – as a very flexible mapping analytic solution, ArcGIS projects can grow at an exponential rate, and very quickly any controls you have put in place for data accuracy will no longer be fit for purpose.  Inaccurate data can negatively affect major business decisions: for example road repair might be commissioned based on inflated traffic use, or exaggerated pothole recordings. This can mean substantial capital expenditure decisions are made erroneously.


Given the significant risks involved in allowing a large number of people to have hands-on access to make changes to your apps, you may think that having fewer super users is always the best option. However having too few can slow down the updates and again create some of the risks stated above. Good access control is about having a strategic plan that grows the administration user base as the use of the software grows and then providing adequate training and support to these users.


Talk to a GIS Consultant on best practice RBAC today

Sam Drummond