Polonious Integrations – Our Journey – part 3

by Stuart Guthrie | Jan 25, 2021 | Industry News, News

Where we are now, where we’re going

Our REST APIs have enabled us to develop these rapidly, securely and cost-effectively.

Here are a few, and what we did to expand flexibility, most are completed, some current projects:

Fraud Detection Capabilities	GBG Instinct	We wrote an adaptor to use their XML Web services capabilities, their team wrote to our REST APIs.
	FRISS	We are writing a Spring Boot adaptor to take JSON about a claim and all of its details and create a case with all relevant details using our own REST APIs.
	Shift Technologies	We wrote a Spring Boot adaptor to take JSON about a referred claim and all of its details and create a case with all relevant details using our own REST APIs.
	Taylor Fry	Two-way integration with Taylor Fry’s Fraud analytics platform.
Case Information sources	CarFax – Vehicle History	We wrote a Spring Boot adaptor between requests in Polonious for Vehicle history and CarFax’s internal API. This returns a detailed car history as a PDF, textual information or both and adds them straight onto the case with a simple button click in Polonious.
	Social Discovery Corporation	We wrote code to interact with SDC’s team to begin a Social Discovery. The generated report is loaded back onto to the case once complete. User just clicks a button to request a Social Search for a Person on a case.
	TransUnion	We wrote a Spring Boot adaptor to connect to TransUnion’s search capabilities. We have integrated some of the more popular searches with a long term goal of covering the full range. These are configurable in the case view interface.
	Clear Data	We are currently working on this integration.
	Carpe Data	We wrote an integration to return social ‘hit’s from a person’s core information.
	Whooster	Public and Private Data Sources. Real-time Current and Historical. A proof of concept has been completed.
	Truepic	Truepic is the leading photo and video verification platform.
Video Interviewing	SimpleToConnect	We wrote code to talk to S2C’s REST APIs which means in the user interface we can provide video interviewing capabilities easily.
Claims Systems	Guidewire ClaimsCenter	We used the new DevConnect to talk ‘REST’ to and from the Guidewire Claims Center system. On a Claim, service requests can create cases in Polonious, all or some updates on the case can be returned to the Claims team via the DevConnect REST calls. Even documents and images can be shared, all seamlessly from both tools.
	Duck Creek	We’re currently working on this one.

Accounting Systems	QuickBooks	We integrate with Quickbooks REST APIs. This is now at the User Interface development point. Once complete, a more seamless creation of invoices and reconcilation interface will be available.
	Xero	We wrote REST APIs that help us integrate with Xero. This will use the same UI as the Quickbooks integration.
Link Analysis	I2 Analyst’s Notebook	We added GET capabilities around entities that i2 might need including cases, persons, addresses, organisations, assets and other entities. This allowed the i2 partner to develop a plugin using i2 plugin design tools in .NET. This integration is owned by the i2 partner.
	Maltego – Plugin	Polonious UK wrote a Maltego plugin that talks to Polonious given information like case numbers, persons and ‘expands the graph’ in Maltego using our REST APIs
Customer Integrations	Major Australian Bank	REST APIs to integrated with core services to facilitate case creation and updates from fraud analytics tools.
	Major NZ Insurer	REST APIs to integrate with their reporting systems written in Power BI. Customer did everything with minimal need from us other than the API documentation. Also a bespoke Guidewire integration using JMule written by their team to a v1 version of our create case REST api.
	Major US Insurer	Integration with their Claims platform via REST calls. Minimal involvement with our IT resources.
	Sales Force	Totally written by the Chinese IT team at a client site. This allows their sales reps to trigger a Brand Fraud case in Polonious when using a sales force mobile app in the field.
	Sumo Logic	Currently work in progress to deliver case outcomes back to sumo logic from triggered case.
Internal Polonious Integrations	AWS Amazon Cloud Automation	We wrote a comprehensive integration set that used our own REST calls to send and receive updates from automation of EC2/S3/VPC/RDS/IAM instance set up triggered from actions taken on cases in Polonious. Bizzare use-case but shows the capability well.
	Twilio	Text Messaging integration
	Google Authenticator	Mulit-factor Authentication Integration (work in progress)

Flexible Integration both ways – inbound and outbound

One of the core strengths of our case management system is that is is very flexible and adaptable to differing business needs. This is a great thing for our customers but a bit of a pain for the development team internally when adding features.

Every development sprint we do has to be predicated by the fact that we need to cover bases for all our customer needs now, and into the future.

Our REST APIs reflect this, and our future road map for them will take this a step further.

This final section is more for your IT teams to understand our approach and how it helps their efforts to integrate with our solution.

Create Case flexibility

Create Case is our most used API, it’s the gateway to initiating action inside Polonious for some trigger like Fraud detection or a referral from Claims.

This API has its own web interface to enable pretty much anything to be used as data to create a case. The interface allows a user to configure a mapping of inbound fields by uploading an example JSON. This JSON needs to be ‘flat’. ie the data has to be a single level of attributes. This actually covers off on 95% of our integration needs with the backup of additional REST services for the more complex cases where, for example, variable numbers of participants are involved.

Outbound REST Call flexibility

Our Polonious customers are now very familiar with the ability of Polonious to automate outbound integration tasks.

To achieve this, we often use a key transaction point in our application, the Case Note (or action, diary, update as some of our customers call it).

This means, you may want this integration to only happen at case inception, or at case review or case update, or possibly only at case close stages. Possibly at all of the above. Our Polonious Persons can configure this for you. No Polonious IT resources are usually needed.

How this works is fairly straight forward. For any type of case note, you can setup a REST call that can locate, collate and send any case data from that case (I mean any case data, including other diary entries, person, vehicle, company data from the case, any metrics gathered on the case either singular or as totals).

Our Polonious Configurers understand how to access the deep case data and can share many examples of how to use it with your team. The technique is pretty easy to use if you’ve used a templating/programming language before. This generally needs no input from our internal IT team reducing costs and speeding the process.

For complex integrations we use an adaptor

In many of the more complex needs, systems talk different protocols and need ‘cleansing’, selection or verification of data on the way to their penultimate system. To do this, we use microservice adaptors. These can be written by our teams at Polonious or your own IT teams. They can be written in any language your team is comfortable with. We have customers who have created these adaptors in languages other than Java such as python, c# and used them to

talk to/from all sorts of different protocols like webservices, sftp,and the like.

The end point for this payload can be another system you’ve designed that talks any of the major security protocols or it can be an ‘adaptor’ web server written in any language (we prefer Java but some customers use node.js, .net, python and others. That adaptor can then forward the data (possibly after adapting it) to your internal applications in a way they understand.

Using an adaptor provides the additional benefit that the integration source code can be maintained separately from the core systems at either end. This makes updating and writing automated tests for it far easier. It also makes it much easier to understand to a new developer which improves maintainability and change cost. Due to the versioned APIs we use, this adaptor will not require regular updates to keep up with API changes.

Finally, an adaptor is just that – it can adapt more easily to internal security changes and other needs. We can easily send you more information (just by changing the payload with a quick call to our Polonious Persons. The rest is easy (excuse the pun), just a small change to the adaptor, re-run any tests, and you’ve updated your security or business requirements. You can change underlying systems with reduced pressures of dependencies as those dependencies are easy to maintain separately from the core systems.

If you are a Polonious client, we have a number of great examples we can share with you of this from our Spring Boot collection. This makes it really easy to stand up a new adaptor as and when needed.

The future

I hope this series has been interesting, it’s a good reflection of how we handle integration needs quickly and securely for on-boarding and existing customers. These are the takeaways that I hope you have seen demonstrated:

Customer and product Integrations have improved markedly in the last 10 years in both speed and cost.
Polonious have developed a great API-first approach to ensure most of your needs ready to be served.
Most integration work at Polonious is done by the business-facing configuration teams, this saves time and money.
The list of Polonious integrations is comprehensive and growing rapidly.

We are expecting a number of changes in the future to our current processes to make them easier to use, more robust, more secure. Currently we’re working on Spring Cloud services and integration technologies. We expect more flexible, scalable, secure and highly resilient services to come from this work.

Additionally, as the Insurtech space evolves, as more and more providers of case information come forward with great offerings, we intend to approach and integrate with all new information vendors as they arrive. To list a few we’d love to integrate with: NICB, Claims data providers, ebay, listings and other information providers.

Every piece of information an investigations team might want to access should be available at minimal effort to the team involved. No special interfaces, seamless integration available as simple button clicks is the way of future. Information sources that require special re-typing exercises will likely suffer in this changing landscape.

The future of case-related information at speed is looking great, we hope you enjoy the journey as much as we are.

Polonious Integrations – our journey – part 2

by Stuart Guthrie | Dec 2, 2020 | News

This is the second part of our three part blog series about our Polonious Integration journey. We hope it’s useful for IT teams and businesses seeking to develop their integration practices, integrate with Polonious or hopefully both. If you haven’t read part 1 yet, it is here.

When the light bulb went on

Around 5 years ago, our transition started to a newer, more flexible integration capability. Most importantly for our team, this also meant less time spent on integration and a whole lot less stress on the projects involved.
The reduced IT spend on Integration meant smaller invoices for customers and more time for core UI and micro service developments that are starting to really bear some fruit.
We still encounter integration challenges, however they are quicker to resolve with minimal interactions. Once all parties understand how to operate, we can break down these project meetings into three to four distinct groupings:

1. Business discussions between our business facing experts and the customers front-line business people to determine the business requirements. In particular – what data needs to be transferred between which systems and what should the high-level workflow look like.

2. Technical integration discussions with client IT systems owners to discuss the business requirements and discuss the technical approach. This includes determining the relevant endpoints, the communication methods / protocols to use, and what authentication methods are supported.

We also have some internal discussions in case we need to write an adaptor to deal with translating the other parties preferred communication method to ours. We then work with the systems owners to determine the technical details to implement the adaptor.

3. IT Security and network discussions. No business users needed. Generally these are fairly rapid as we are well across all security / technical needs and are ISO27001 certified, which means we follow best security practices and generally have great solutions for security related questions.

How we made the transition

To move to this better place, we needed to create tools that allowed the business users to have discussions about ‘what goes where’ without any IT involvement.

This required building secure, flexible REST capabilities for our primary integration driver. In our world, this was ‘Create Case’.

REST APIs actually date to the early 2000’s. It wasn’t until 2014 that they became widely acceptable as an alternative to XML Web Services and other protocols commonly used by large corporations. The reasons for this change were the ease of adoption by other teams, the speed, simplicity and flexibility of the specification.

We started around this time to look very closely at REST capabilities and decided to re-develop our case ingestion to have a REST API.

Flexible REST

Most REST APIs are fixed in nature, you get a few fixed parameters, well documented and defined which you can POST (in the case of creating things) but these are not very adaptable.
To meet our need to ensure the ‘what goes where’ conversations could happen without our IT team involved, we had to develop a very adaptable, configurable, Web User Interface for this crucial service.

So our Create Case REST API is actually up to the customer. What fields are POSTable, is defined in a web interface, how our POST api responds to these is also up to the customer. By doing this, we can handle 95% of create case needs. For the rest, there are adaptors.

The upside for our customers

Since this capability is now an easy to use part of our user interface, it’s really easy not to involve internal IT teams (from both sides) in the many of the conversations required to get business data transferred between systems. Here is how the conversation generally goes:

Polonious: “Send me a JSON example of what you want to send to us”

Customer: “What’s JSON?”. A short discussion of this format ensures, usually we send a simple example over like this:

{

“claimNumber”: “GHT202320”,

“referralReason”: “Claim initiated within 7 days of policy inception”

}
Customer: “Ah, I get it!”… sends example of data to be used to create case.

Polonious: “Here’s a few things we need to alter and discuss” this is usually a short discussion about types of fields, how fields should be formatted etc. This can involve customer IT, or that can be deferred to an adaptor we write to absorb whatever is easiest to send from the customer’s end.

Customer: “OK, that’s it, we’re ready, here’s some examples of what to load”

Polonious: “I’ve mapped them using our create case api tool, here’s the URL for your team to test it, here’s some test credentials to use, here’s where it will appear”.

Customer IT and our IT then usually get involved if there are firewall/network/other issues with data. This is often a fast process as it’s a simple port 443 request (secure TLS 1.3).

Polonious: “Looks like the cases you send created successfully, let’s get back to talking about the process you need to follow up these cases, and what the feedback loop looks like”

If everyone is available, networks are in place, this process can be over in hours. This used to take days, weeks, months of elapsed time depending on availability of many parties to the discussion.

Learning: As REST services expand, integration projects shorten

The rather unscientific graph on the right shows effectively what’s been happening for the last 5 years at Polonious. As we invest more time and effort into our REST services, the time taken to integrate to new platforms decreases.

Crucial to this transformation was understanding the best way to structure our REST services. There are conventions for naming and versioning REST services that are important to provide these advantages:

- Conventional naming of APIs means quicker adoption by IT teams wanting to integrate to your services. This book was a lot of help: https://www.manning.com/books/irresistible-apis
- REST service versioning means IT teams do not need to re-develop their integration to your software every time you alter the API. Believe me, they don’t want to.
- Documentation. Great API documentation greatly speeds adoption of your APIs to other IT teams. We invested a considerable amount of time in explaining, in documentation what our services do and how to use them. We even wrote an SDK in Spring Boot to demonstrate using them in Javascript.

For us, the first step of the API journey was making our own ‘case intake’ web forms use REST APIs instead of requiring Java engineers to bespoken write each of them in our chosen tool (Java/JSP).

Doing this, expanded our public APIs to cover most GET requirements an external team might need. This further shortened integration projects.

We can now hand over web form development to any client team willing to invest a little in learning our REST APIs. Of course we’re still available if clients don’t have capacity. Many client IT teams have done this. We hear all the time of IT teams building REST calls to our system with web forms or other means. This is great for all concerned as it saves ours and our client’s time and effort. Since our key system updates and reads are now wrapped in REST calls, we are pleasantly surprised by the capabilities client’s teams have developed with these APIs. A recent example was a team developing a button on a sales force mobile app, this button was used by sales reps in the field to photograph potential fraud and have immediate cases created in Polonious to process the leads from the field.

Learning: As external teams need more information, add that to your REST APIs first

We integrate to our own client’s internal systems, but also to other partners in the vendor space. With each information need a client expressed, our process became ‘REST FIRST’ which meant we expanded our REST APIs as these needs evolved over the last 5 years. This has had a profound impact on how easy it is for a customer to integrate to our software.

In the third and final part of this series, we will go over the integrations we have developed to other systems and where we’re expecting to take this capability in the future. Thanks for reading so far, I hope you enjoy part 3.

Polonious Integrations – Our journey – Part 1

by Stuart Guthrie | Nov 21, 2020 | News

Integration, done well, is a powerful time-saver for a business. Data magically moves from one system to the next with no re-typing or errors. The business cost benefits are immediate and cumulative.

IT Integration projects used to be slow and expensive. Polonious have been on a journey to improve this over the last decade. We now know that we, and our customers can be confident integration challenges are not the painful undertakings they once where.

Polonious currently have 21 product integrations that push and pull data from many sources including:

Investigation information sources (7)
Claims systems (2)
Fraud analytics products (4)
Video interviewing systems (1)
Accounting systems (2)
Link analysis systems (2)
Others (3)

We also have many more integrations to internal client systems scattered across a multitude of data sources, methods and security protocols.

Each of these integrations built on the methods of the previous one. All have the same foundations to their success.

This integration series will explain what’s different about our approach and why we are great to partner with if integrations are something you’re concerned about.

Part 1 is concerned with the state of integrations when we began the journey, what the problems and frustrations where and a little bit of a look ahead to what our principles for integration became.

Part 2 covers the first pieces we use to ensure significant cost and delay is removed from integration projects without causing quality and security issues. I’ll discuss the lego blocks that make up an easy integration process.

Part 3 covers our current list of integrations to give an example of what’s possible for your business, as well as some of the more complex components we wheel in for complex requirements. One thing that is pleasing is to see our clients take our API sets and use them in place we never expected. Sales reps triggering fraud cases from Sales Force Mobile being one recent example. We will also touch on the future, what we’re doing next to further help with the integration needs of our customers.

Our journey

A decade ago, when Polonious needed to integrate to other systems, this was how the projects generally worked:

Big budget integration projects.
Regular, big, team meetings involving project milestones. Participants included the business, IT network and security people, IT development teams. Lots of discussion about approach, governance, everyone being heard. Very expensive undertakings.
Waterfall project plans which coordinated the efforts on both sides of the IT discussion.
Delays by any part of either party’s team slowed the whole project down. For example, we once waited 9 months for the other party’s FTP site to be set up correctly.

I and many or us at Polonious were very frustrated with this process – we knew a lot of it was out of our hands. Unlike many things in the IT world which had clear paths and standards, a lot of the issues we encountered were associated with ‘bikeshedding’. By way of example, here are some of the long discussions from those days:

Security. Many teams we encountered needed a detailed discussion of how we were communicating securely. They often had different thoughts and requirements that needed to be discussed and agreed upon.
Protocols. This was the glue that allowed systems to communicate. This varied from SFTP / XML / Webservices and other methods. A lot of people are still used flat file importing also.
Field discussions: what goes where. This was to the most point a business the discussion that required IT resources. These discussions shouldn’t have needed IT resources.

Integration projects accounted for at least 30% of our IT resource budget most years until we spent the time to work out how to get control of this process. As a bonus, during this time, the IT world moved on a little – clearly we weren’t alone in these frustrations.

We believe that we now have the integration challenge down to a fraction of it’s previous frustrations and delays. I’m hoping that this little series can help a little with your team’s challenges, if not, with understanding our approach and how that can help if we need to integrate together someday.

Here are the main points of advice I’ll be covering with examples of where it’s worked and how it works for us and our clients:

Fix your integration efforts on secured REST, preferably with OAuth2 – as soon as possible.
Make your REST services flexible enough so that business people who will use them. Yes, business people..
When considering working on integration, start with improving your core REST services, the next integration project will benefit from it.
When you can’t use REST – adapt. Write adaptors to translate the other party’s communication needs into your common REST calls so that all of your internal verification, security and updates are consistent.

Of course, I’d love feedback on this as I’m sure the journey is not complete. You can reach me by email here: stuart@polonious.com.au or by linked in here. Part 2 follows next week.

Polonious Release 20.2 Announced

by Stuart Guthrie | Nov 5, 2020 | News, Uncategorized

Polonious release 20.2 is ready for all clients with some great new features that we know will improve your team’s productivity, user experience, and capability.

Version 20.2 further enhances the front-end with new Dashboard technology which was introduced in version 20.1, adding eleven (11) SmartWidgets to enable you to build any sort of dashboard your team needs. This allows you to create dashboards from any case data quickly and easily.

Additionally, we have added a Document Library feature to help your teams use the same documentation, we have expanded our list of integrations. We have also added better, more secure Multi-Factor Authentication methods.

Analytics

Release 20.2 includes a full set of Charting capabilities that enable end-users to construct dashboards that total and drill through their Case Management system.

A full set of capabilities

Eleven new dashboard SmartWidgets are ready to use:

Pie Charts

Bar Charts

Sunbursts

Circle Packs

Treemaps

Stream Charts

Data Aggregators

Tables

Maps

Time Series Charts

Counters

Dashboard Layout Manager

This drag-and-drop capability allows your configuration team to layout the dashboard views in an easy-to-use and configurable way.

For example, we have created this dashboard view layout from the SmartWidgets available on the left by dragging, dropping onto the rows, then configuring each SmartWidget in a simple user interface.

When you render the dashboard from the above layout, you will see something like this:

You can control the width of each widget as well as the contents. You can fit as many as six widgets across on wide screens. When this renders to mobile devices, it puts only one widget across and displays them down the page. A responsive design that enables our dashboard tool to adapt to your device size.

Document Library

The Document Library allows users to create a library of essential documentation shared according to security access with various teams and external vendors. Making it easy to update and share essential compliance, process, and form print requirements in one central location.

Security – MFA with Google Authenticator

With 20.2, you can now use the popular Google Authenticator to generate multi-factor authentication codes, instead of entering a code sent to your mobile device by text message or email.

Google Authenticator is a more secure method of generating MFA codes than using SMS or email delivery, as it cannot be as easily intercepted and changes values every minute. It is also explicitly tied to a user’s mobile device.

Integration with Simple2Connect

Full integration with Simple2Connect’s video interviewing software makes it very easy from the case management view to request and start a new video interview. The final video is uploaded automatically to the case notes upon completion.

Integration with Guidewire DevConnect

Guidewire created DevConnect recently to enable easier integration with their Claims Center product. Polonious had already successfully completed the accelerator several years ago. This new method is the preferred way to connect to Guidewire going forward; this September 2020, we received certification with DevConnect.

REST API Improvements

We added two new secure communication options in 20.2, which extend the integration capabilities of Polonious with other products.

Basic Authentication Header capability was added to allow REST calls to services that are protected by Basic Authentication.
JWT (JSON Web Token) was added to enable calls to services protected by JWT.

We have also added many improvements in payload contents and API endpoints. As always, backward compatibility of payloads and requests is preserved to ensure that existing integrations with Polonious continue to operate without modifications on your end.

Other improvements

This release has implemented many more features whose full details are in the release notes and user guides available from Polonious on request.

Full release notes (pdf) and a comprehensive user manual are available on the user group for current customers. Please contact your representative for more information.

Links and contact information

We are always looking for feedback and thoughts on our software, please contact your local Polonious office for more information, help or feedback. We’re keen to keep improving.

Related Articles

https://polonious-systems.com/polonious-analytics-a-first-look

Video demonstrations

Analytics - a first look

Request a demo

Polonious Analytics – A First Look

by Stuart Guthrie | Nov 5, 2020 | News, Security, Uncategorized

This is a demonstration of our new Analytics capability, which is part of our 20.2 release.

This demonstration will show you how easy it is to create a useful and visually compelling dashboard specifically, in this case, to help with team coordination.

We will build this dashboard in 10 minutes, stopping here and there to explain some of the capabilities and concepts.

We believe your team can take on the task of building their own uniquely useful dashboard views into your case data.

So how does Analytics help your team?

Analytics give them the ability to:

Prove your team’s value to the organization.
To create greater efficiencies by analyzing performance.
To track Compliance by examining the data you can easily capture on compliance KPIs
To improve referrals to your unit by examining past cases referred vs case outcomes and savings.
To measure quality by creating dashboards to measure the quality of work our vendors and team are doing

Drag and drop, configure, run..

View, filter, list and then view cases.

So, what did we just see?

The dashboard build took around 10 minutes with stops to explain some of the concepts.

I think you will agree, it was easy to drag, drop and construct this dashboard.

We believe you can do this task now with no IT involvement required. This is a big saving in doing time, turnaround time and internal costs.

So what did we just see in terms of Polonious Analytics capability?

You can easily filter and select the case data you need to answer your questions.

There are a bunch of smart widgets to visualise your data as you need.

When you are using the dashboards, if you see something interesting, it’s very easy to drill down to that detail and see all cases in a list represented by that point of interest.

You can view a case straight out of that filtered list to see the full detail of what went on during that individual case.

What else can we do with this new capability? What are the other possibilities?

Rick Shepherd and Steve Epstein of Polonious gave a metrics presentation at IASIU on the key areas analytics help a team such as yours. Proving Value, Improving Referrals, Creating Efficiencies, Measuring Quality and Compliance. All of these are now easy to create with Polonious Analytics..

We hope you enjoy our new 20.2 release. We really look forward to seeing what your team are able to put together with this new capability.

If you have any questions or improvement suggestions, we are very keen to hear from you. Thank you.

« Older Entries