In a recent implementation of Workforce Management, we were given the task of creating a "Pole Manager" to track additional information about the poles that were currently installed in GIS. The goal: allow users to easily view and/or update details about poles, including testing and contact records, and to view overall reports on these poles.
Poles in this system are stored based on their location in GIS. Users can look them up based on this location, and (depending on their WFM permissions) can update data accordingly for the pole. This includes records for pole testing and pole contacts. We gave users a quick look at all the available records in both categories, and a quick way to delete, view, edit, or add from that area.
There were some challenges to the design of this feature:
- Where do we store the data? Asset management outside of GIS frequently has potential for data redundancy. The information about these poles should be stored with the WFM information, but some of it also exists in GIS. A commonly-encountered dillema has to be resolved for most asset management tools during their design phase, and the solution often depends on the environment and the tool you want to build (or the one you want us to build for you).
In this solution, we decided to store most of the data solely in the actual Pole Manager tool, not in GIS, so that it can be easily edited at any time from the tool without syncing data back and forth, and so the data would be less redundant. One of the larger downsides to this is that any data that exists in GIS also can be versioned and edited in GIS during designs and edits. This has been mostly alleviated, though: with WFM's thorough permissions and roles system and its integration to Active Directory, authorized users can still be defined at a completely thorough level, and we additionally built a quick tool that allows users to right-click a pole in GIS and instantly bring up that pole in Pole Manager.
That's not all, though. There were some fields that were necessary and made sense to track only from GIS, not Pole Manager. We wanted them visible in Pole Manager without having to add steps to keep data in sync.
In this scenario, we searched the GIS multi-version view from WFM and displayed read-only data on the values we found. This allows users to see what the pole's GIS data looks like in the default version.
- How do we integrate with existing systems? We didn't want users to have to manually go into Pole Manager to add poles after having just added them in Designer™. Additionally, with our workflow in WFM, designs can be rejected, or a design can be updated with as-builts and posted long after the design is made and approved. Moreover, this environment uses dynamic location numbering for poles - they don't even get numbered until they're approved or posted to the default version. Users wouldn't even be able to add poles until they are numbered automatically. The best option for us was to handle the pole creation ourselves. Often, this can be done when a pole is posted, but we needed to ensure that our interface for numbering a pole had occurred before we created the pole in Pole Manager. As a result, a pole is added to Pole Manager as soon as it is numbered (either upon posting to the default version, or reaching a certain point in the WFM workflow) by our Nightly Batch Suite.
We also wanted a little more functionality and flair to add here. Remember our Hyperlink Manager? We've integrated it directly into the Pole Manager tool. The environment here uses location as a driving factor for their hyperlinks, so we added a list of hyperlinks that users can view right from WFM's Pole Manager for a given pole - provided the hyperlinks are stored on an accessible network share or website.
The result became an effective and useful way to track, store, and report information about poles, built right into WFM! If you want to learn more about how we can tailor WFM to you, check out our WFM Services page, or contact us at any time.