Building an iManage SPM Integration in Three Hours - and Why Architecture Matters

Recently, a customer asked us if we could integrate our platform, Jylo, with iManage SPM. Rather than turning it into a months-long project, we sat down with the customer and got it live in about three hours. Three very experienced software engineers, one focused session, and a lot of “vibe coding.”

The integration sits between the iManage SPM cache and Jylo. The customer runs iManage in the cloud but maintains an on-premise cache of policies so they can securely manage other systems in their environment. From there, we connected everything directly into Jylo’s API at https://developer.jylo.ai. The whole process was a good reminder of how much easier integrations become when the architecture of your platform is designed the right way from the start.

To understand why this was possible, it helps to look at how ethical barrier technology has evolved over time.

In the early days, ethical barriers were often implemented using SQL triggers. These triggers would monitor database inserts or updates and, if a change breached a policy, the trigger would reverse it. On paper, that seemed sensible. In practice, it caused serious problems.

At one firm I worked at, there was a single workspace in the document management system containing around one million items tied to a highly sensitive matter. About once a month, someone would change security at the root workspace level. The resulting cascade of insert and delete conflicts would bring the entire library down. It was a clear lesson: SQL triggers were not the right tool for managing ethical barriers at scale.

The industry then moved toward API-driven barriers. That was definitely an improvement, but it still had issues - especially when ethical barriers were added as an afterthought to document management system design.

The core problem is that many DMS platforms allow a mix of public and private security models at different levels. You can have public workspaces with private documents and private workspaces with public documents. From a security perspective, that’s difficult to manage. It means external systems have to apply API transactions to every individual object.

In large, complex systems with massive volumes of content, the rule is simple: there will always be some level of error. During several DMS migrations, we’ve seen this firsthand. Files inside barriered matters sometimes ended up with inconsistent ACLs. Not a huge number - maybe 1–2% - but enough to create real risk.

So item-by-item API calls aren’t the answer either.

What the industry really needed was a simpler model: effectively an on-off switch. Think of it as the difference between having a single key to the front door versus putting a padlock on every item inside the house. Security is flattened across the matter or project, and you’re either in or out.

This is what the iManage SPM architecture has today and is definitely a great improvement on the old days. Jylo has been built to mirror the same "key to the front door" architecture.

At Jylo, our belief is that users don't need granular document level security choices. It often leads to inconsistent and misunderstood security models where information ends up being accessible when it shouldn’t be.

Instead, we built our system around zero-trust principles. Document security is flattened across the project. You can’t make documents public inside a private workspace, and you can’t make documents private inside a public workspace. In practice, there shouldn’t be massive workspaces trying to support both. Instead, it’s better to create many smaller projects with clear boundaries rather than confuse the security posture.

Because of this architecture, integrating with iManage SPM turned out to be really straightforward. Our Jylo Teams ACL API made it possible to connect everything quickly and cleanly.

The process worked like this. First, we query the SPM cache to retrieve the client, matter, and the policy defining which users are allowed into that matter. Next, we use Jylo’s project metadata settings to attach the client and matter as objects on the project. These are then bound so the policy aligns directly with the corresponding Jylo project or matter.

From there, we iterate through the project Teams ACL to identify differences between the users in Jylo and the users defined by the policy. Anyone not included in the policy is removed, and anyone who should be in the workspace but isn’t yet is added automatically.

The customer already had an orchestration engine that runs various integrations across their environment. They simply added this integration to their schedule so it runs regularly, ensuring that sensitive matters always remain aligned with the official policies.

In many ways, Jylo was already close to this model. We don’t have a concept of a public workspace, and unlike many AI tools that act as personal assistants - which can completely undermine ethical barriers - Jylo is built around matter-based collaboration. People can’t overshare, and everything is structured around the project.

There was, however, a small gap. Project administrators could still add someone to a workspace before risk teams had reviewed or approved them. This integration effectively closes that gap by ensuring access is always synced with the official ethical barrier policy.

Across the legal industry, firms are at very different stages of their DMS evolution. You often see multiple vendors, multiple ethical barrier tools, different versions of each, and a mix of cloud and on-premise components. It’s a complex ecosystem.

What this experience reinforced for us is that the most important thing legal AI vendors can do is build advanced APIs and design their systems to align cleanly with existing enterprise legal technology.

When that foundation is in place, integrations that might otherwise take months can sometimes be done in a single afternoon.