In 2010, insurtech was in its infancy.
At the time, insurance claims processing was still a mostly manual endeavor, defined by mountains of paperwork and multiple field agents.
Yet, the consumer demand for seamless service was just beginning, and insurers were struggling to keep up. It was during this time that insurtech took off, and subsequently, Snapsheet was responding to the growing need for innovation within this fledgling tech sector.
Since its inception in 2011, Snapsheet has undergone tremendous growth, amassing an army of over 400 techies scattered across the globe. But don’t let their size fool you — the company has all of the trappings of a fast-growing startup.
Just as Snapsheet’s employee base has grown, so, too, has its technological tool belt. After all, building an efficient claims system takes some serious tech innovation.
Alongside his fellow coders, Snapsheet Staff Software Engineer Nick Stanish is spearheading the company’s efforts to build a user-configurable workflow automation system, which will make the claims process easier to understand and more applicable to clients’ specific business needs.
Given the complexity of Stanish’s current project focus, it’s no wonder that, when asked to describe Snapsheet’s engineering culture, he chose the word “iterative.”
“Sometimes, there will be pain points, and that is something to be expected at any company,” Stanish said. “We actively try to discuss anything that isn’t going well and try to find solutions.”
Stanish gave Built In Chicago an inside look at the ways in which his team — and the company as a whole — is developing workflows designed to better meet the needs of businesses.
Snapsheet at a Glance
- Who: Snapsheet is an insurtech company that aims to “bring the future” to auto claims processing.
- What they do: Utilizing data-driven automation and AI, the company offers businesses virtual appraisal, digital payments, rental and asset management and cloud-native claim management solutions.
- Why they do it: Through the development of its auto claims processing technology, Snapsheet seeks to enable businesses to focus on resolving claims faster and more accurately.
Can you tell us more about the workflows project your team is currently working on?
These workflows allow our clients to drive automation in our system to meet their specific business needs. Previously, this level of customization would require code changes and many logical branches that can quickly become unmaintainable or slow to deliver.
What technologies are you and your team members using for this project, and how are you using them?
We didn't need to add any additional infrastructure to support this project, but we added several libraries and processes in order to streamline development. Our stack primarily features Ruby on Rails and MySQL for the back-end APIs and statically-hosted, single-page apps in React for the front end. We built workflows as a Rails engine that is published as a private gem. Using a Rails engine helped us accomplish several goals. It made it easy to include in many different back-end services, it enforced clean interfaces and abstractions, and it enabled incremental improvements through versioned releases. We incorporated GitHub Actions to automatically publish to the GitHub package registry when a new version is tagged. We also started using GitHub code owners to ensure code changes are communicated to any necessary teams.
We introduced single-spa to our front-end architecture to reduce coupling and increase cohesion for our application. We also restructured our largest front-end repository into a monorepository with many packages so that workflows UI and its dependencies could be developed and published independently. We introduced dynamic imports to reduce webpack bundle sizes and improve loading performance.
Snapsheet strives to build the most efficient claims system possible, so automating as much of the process as possible is a huge value-add.”
What are some of the biggest challenges your team has faced so far, and how have you overcome them?
There were a lot of challenges with a user-centric approach, the first of which was building a design that would be generic enough to be reused in any of our services, simple enough for a user to configure and powerful enough to allow for major automation. We chose an event-driven design where each configured workflow operates sort of like a state machine and each claim can have multiple workflows active at the same time. Any model could react to attribute changes and emit events. This might be something like a claim’s status changes, a communication is sent or a task is completed. When an event occurs, we determine if there are any workflows to kick off and find any actions that should be performed for the currently active workflows.
Another large challenge was building in safety nets to prevent misconfigured workflows from taking down the system. Our workflow process occurs synchronously within the request lifecycle to have the greatest effect, but it also means that we need to address failures and guarantee reasonable execution speed to ensure services remain available. Failures on any action can be viewed by the user and manually retried. As far as execution time goes, any action could trigger additional events, so it is easy to end up in a situation where a single event escalates into an infinite loop of performing actions that generate more events that perform more actions and generate even more events. We solved this by setting a hard limit on the number of events that can be handled per request and an event stack to stop execution based on depth limits as well.
How have you and your fellow engineers supported each other throughout this project?
This required a lot of communication, documentation and whiteboarding. A complicated topic like workflows can be difficult to fully understand. We needed to make sure that everyone is on the same page about what the MVP is and how to iterate from there. We came up with scenarios that we needed to support that we could reference to shape requirements. We defined terms as a glossary so that we can distinguish between a “workflow definition” (a user-defined configuration for how a workflow should operate) and a “workflow” (an instance of a workflow definition that is attached to an object such as claim). We were careful to document any tradeoffs of our decisions and assumptions so we can reference them in the future as requirements grow.
A Love For Learning And Discovery
How does this project tie into Snapsheet’s mission?
Snapsheet strives to build the most efficient claims system possible, so automating as much of the process as possible is a huge value-add. Users can customize this automation to handle their business needs and update them as their needs change. This allows developers to focus on building functionality and extension points that are usable by all clients instead of a single one, and our product and strategy teams work with the customers to ensure that we support any events or actions that they would like to configure.
