While our engineers are hard at work building a flexible platform that suits the needs of our diverse user base, we often receive feedback from users exploring the software (or potential customers) and requesting very specific features, totally unique to their workflow.
Fulcrum would be perfect for our use case if it just did this one super specific thing that no one else in the world cares about except me…
User feedback is critical as it helps us better understand how folks are using the platform and where their pain points are, but some requests are so specific they will never be built into the core product.
- I’m using Fulcrum to do address verification and need to include street names from my GeoServer instance in a choice field.
- I need to verify that my field crews are taking photos onsite when they are collecting the record, and the photos must be in landscape orientation, and geotagged.
- I need specific control over which users have access to which fields and when. For example, a manager should be able to see and edit everything, but once the status has been set to “Verified”, the record should be locked down so no one can modify it. Field crews should never be able to see anything in the “Quality Control” section and should not be able to set the status to “Verified”.
- I need to implement some custom geofencing logic, which restricts certain users from collecting or updating data outside of their defined jurisdiction.
Moving Beyond Form Structure
To address these challenges, we needed a way to give users more control beyond just the structure of the form and field visibility / requirement logic. We needed a mechanism to hook into events (photo attached, record saved, location changed, etc.) and perform customizable actions (alert the user, filter choice lists, set readonly, etc.).
These actions needed to be scriptable, allowing complete workflow customization logic to be implemented at the form level, by the customer, without requiring any interaction from a core developer.
Launching Data Events
When we launched Data Events back in March, we knew that this was a game changing feature for our platform. Unlike most new features, which add some tightly designed core piece of functionality, Data Events opened the door for users to design their own custom workflows and processes within their data collection forms.
Real World Examples
Below are some real world examples of how folks are taking advantage of Data Events for workflow automation, quality control, translating and more!
Query a GeoServer instance
This example demonstrates how to build an OGC Filter to query a GeoServer WFS instance and use the results in a choice list. For this particular example, we want to list all the streets within 100 meters of our current location so we can do some field addressing without having to enter the street names. MassGIS maintains a GeoServer instance which includes roads from the Massachusetts Department of Transportation (MassDOT). We will be querying the massgis:GISDATA.EOTROADS_ARC layer, parsing the results as GeoJSON, and adding the STREETNAME property to a choice list.
Dynamically translate form elements
Compare photo location to record location
This example demonstrates how to add quality control checks on photos by checking to see if they were taken in the same geographic area as the record. If the photo’s geotagged location is more than 20 meters from the record’s location, the user will be alerted.
Launch Google Street View
This example demonstrates how to launch Google Street View at your record location on both mobile and web. It passes the record’s coordinates to the OPENURL function, which invokes the Google Maps Streetview app on mobile or opens the Google Maps website in Streetview mode on the web.
If you’ve built some interesting workflows with Data Events, we’d love to hear from you. If all this sounds intriguing, but feels a bit overwhelming, our Professional Services Team is always available to help build out and script your custom workflow.