Investigations are carried out across various business units and teams in an organization – HR, Information Protection, Corporate Security, Cyber Security, Brand Protection, Physical Security, Insider Threat, Customer Services and Health & Safety to name a few.
Most teams will have a method of documenting their investigations and tracking progress and outcomes. Depending on the maturity of the company this could range from spreadsheets and emails to large enterprise applications. This is extremely inefficient and costing companies in terms of time, money and strategic outcomes.
By implementing a single system to carry out investigations, you can unite teams from across the company – sharing skills, knowledge, and best practices.
It’s never an easy task to rationalize systems from different business units, but the business case to do so can be compelling and the benefits felt across the wider organization.
Here are a few examples of benefits:
IT Support – A single system to support, administer and assure.
Split Costs – Licensing split across many business units.
KPI/KRI – Single source of metrics.
Automation – Reduce manual activity and increase throughput.
Consistency – Even with different processes it’s easy to ensure a robust investigation takes place.
At Polonious we often help to rationalize systems and build bridges across business units. Want to know more? Contact us at email@example.com
Investigations are carried out across various business units and teams in an organization – HR, Information Protection, Corporate Security, Cyber Security, Brand Protection, Physical Security, Insider Threat, Customer Services and Health & Safety to name a few.
Our new View Layout Builder, which was introduced in Polonious version 20.1 got additional capabilities with the recent 20.2 release, which we are introducing in this blog post.
The embedded video showcases how to configure a couple of widgets in the new view layout builder. This is an introduction to the ‘What You See Is What You Get’ configuration functionality being rolled out wherever possible across the system.
We have a number of very cool widgets available which we explain in a full instructional video we have available on request. However, for now we want to demonstrate the process of configuration with two basic widgets.
An important note on the new case view builder is that you can create a different view per case type. So you can e.g. show more photos on a surveillance case, fewer photos but more data on a factual or forensic case, and so on.
We believe your team can take on the task of building their own case views into a powerful, at-a-glance summary of the information most relevant to any particular case type.
So how does this help your team?
- Easier configuration of case views – drag and drop widgets.
- More flexible case views – move any info, anwhere.
- More specific case views – more relevant info on cases.
Drag and drop configuration.
In addition to being easier to build, the new Polonious view is much more flexible, and much cleaner.
So, what did we just see?
In an 8 minute video we added the main case data. In real life, you’ll do more building but less talking, so it’s very quick to build a whole view.
Different widgets have slightly different configuration, but it all follows roughly the same process. The more detailed widgets add more complexity, but it is still very easy.
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 case view configuration?
You can easily select the case data you need to display for any particular case type.
It’s easy to lay it out in a neat, informative way that looks good in the new Polonious view.
You got a glimpse of the array of widgets available – please get in touch if you’d like to know more.
What else can we do with this new capability? What are the other possibilities?
With this new approach, and with the underlying functionality built out, it’s easier to add new widgets to further improve what you can do with the new case view.
We’ve also made it easier to upload new CSS to change the underlying look and feel in terms of background colours, logos, etc.
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.
Hello it’s Nicholas from Polonious here with a quick introductory video to our new case layout feature. So this feature allows you to move everything around the page and lay it out whatever way you want, and it’s a new ‘what you see is what you get’ drag and drop tool that will allows you to completely change the layout of the case. We do have an instructional video on that coming but it is a 30-45 minute long video so not really good for an introduction. It has all of the details on how to set it up so if you’d like that, please get in touch with us, but for now we’re just going to give you a quick introduction.
So here, as you can see, is the old case view if you’re familiar with it, so on this there’s a lot of things that are fixed, it’s not movable and so what we’re going to do is just take some of this information here so you know what we should be seeing and then go just configure a couple of what we call widgets on the new case view. We won’t put all of this information on here just enough to show you how it works and then if you would like to get a breakdown of more of the widgets or things like that, or how you can replicate this case view then please get in touch with us for the instructional video.
So the first thing I’m going to do is enable a case view here so we’re going to make it the layout view, which is the new view, and we don’t have anything in here yet. I’ve selected this one so if we refresh this case it should go to the new view now, but there’s nothing on here because we haven’t set anything up, but you can see what was supposed to be on there before. So just to give you an example of this we’re just going to drag across say two field lists that kind of replicate that data that was at the stop at the top of the case and then just a table with a little bit of data in that.
So what we’ll do here is on this field list we’re going to grab some basic case data like the case number, a couple of organization levels, maybe a description, notes and a status and that should do us in this one for now. We’re going to select that we want the labels on the left, so this is just the names of each field that will be next to the values that tell you what it is. We’ll grab the details now, they can be left as they are and they will display like this or you can change them – so most of this is okay except this one doesn’t look particularly user friendly so we will just call that case status – and here you can change the number of rows, font size, formatting to make the labels look different, this is just the labels for now, and then we can also name the whole field. So this is to make sense of it in this view you can just name it as that and leave it with no heading or you can give it a heading and actually make it surface on the case view as well. Then you can justify that heading similar to what you can do with the details here, and then lastly we’re going to give it a size.
So everything in the new view the sizes are in fractions and that’s because the new view is responsive as well, so we don’t want to say it’s x number of pixels because then if you move between a big screen and a small screen and a mobile device it’s going to end up looking really strange with a lot of blank space or spilling over and having to scroll. So here you just set it out in rows that represent you know a kind of a full screen width or a couple of screens in length and then you set out a fraction so they space themselves according to the size of the screen, and if you’re on something really small like a mobile they’ll line up and down so that you can scroll through and it works better on a mobile. So for here we’re only doing two widgets on this line so we’ll make it a half. We’ll grab this one and just call it dates and financials and we’ll just grab a couple of dates here, allocated and completed is good enough for an example, labels on the left again, details we’ll leave as they are, and we’ll call this dates and financials and give it a heading, make it half again. So that’s your basic field list widget that lets you pick data and just basically display the data as is with the label on the left and the value on the right.
Underneath that we’re going to show you a table which is useful for surfacing things like people, entities, and assets. We’ve got specific widgets for those as well where they will display a card with more detail on it, but this is a useful view for summarizing people attached to a case and things like that. So it depends on how you want to view that information as to whether you use this or the specific widget. So we’re going to drag a couple of details across here, this is a new thing where you can combine the last and first name – they’re separate fields in the database but we can join them and we’ll just call it last name-first name – and that’s just handy for display here. We’ll call this people and give it a heading and then the size, we’ve got one on that row so we’ll just make it a full width.
So then we have a number of other widgets under here which I won’t go into now, but I do explain more in the full video that we’ve got, and so we’ve got a number of graphs that you can show on the case, you know useful things like radar charts good for QA, time series is good for budgets and things like that we’ve got a media viewer so for example if you’ve got a surveillance case you may want to surface photos or an accident case you may want to surface accident photos, cctv, things like that so you can surface that on the front of the case now rather than needing to go into doc preview, but for now that’s enough for our little intro.
So we will click away here and go back to this view and just refresh and you can see this data’s come up now, we’ve got half width for these here and we’ve got a table there and then we can go you can see that it’s pretty much what you see is what you get so we’ve laid it out like this and we’ve got a full width to half widths we can also move things around and so you can see that it’s a very easy drag and drop repositioning through some of those details that I showed you before. You can also change things like font size font color, things like that.
It’s very easy to reposition everything around here and it allows you to put anything where you want it, so it is a lot more powerful than the old case view and it’s a lot more configurable. The other important feature of this is that you can set a different one per case type so for example if you’re a private investigation firm and you have some factual cases and some surveillance cases you may want to put those photographs on a surveillance case but they might not be as important on a factual. So you don’t have to surface those on a factual, you can have more of those data fields where you fill out information that you found. So as I said, we have a longer video available if you want to know how to do this, for now it’s just telling you that it exists and that it’s pretty cool so I hope you like it and please get in touch – thanks.
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.
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:
“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.
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.
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.
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.
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.
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:
Time Series Charts
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.
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.
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.
- Do you find yourself going through lengthy project/budget approvals to make improvements to your system? Are some changes not even worth the budget hassle?
- Do you have operational budget for increasing your subscription, but no capital budget for improving it?
- Have you got the newest features, but no new budget to start using them?
We work hard to constantly improve Polonious software, but these issues prevent some clients adopting our improvements, or adapting to change.
We have heard you, and we are pleased to announce a new, optional addition to licencing subscriptions allowing you added flexibility for improving your system. We have developed a model and a management process for a ‘Change Subscription’. This adds a set number of hours per year to your subscription budget for changes, i.e. system changes that are not bug fixes. This has the following benefits:
- Change budget is already set aside, so you can make changes and improvements much quicker. No lengthy budget approvals.
- Configuration time set aside to immediately capitalise on new features.
- Manage projects through operational expenditure, instead of capital expenditure.
Additionally, we are offering a 5% discount to their hourly consulting rate for customers who purchase more than 20 hours per year as part of their regular subscription. We increase this to 10% for customers who purchase more than 40 hours, 15% for more than 60 hours, and 20% for more than 80 hours per year.
Please note, if you purchase change support with their subscription, this does not replace the normal support charge in your licence subscription. We will still provide support for bug fixes and other errors without taking time from your change budget. We will use the change support budget for design changes, new workflows and so on. Also, if you use the full change budget in one year, you can still make additional changes, but hours will be billed on a per project basis again. Your change support subscription will invoice and renew your hours at your anniversary date each year.