Workspace creation tied to your own matter rules
A new matter in your practice management system creates the matching iManage workspace with your firm's own metadata and security settings already applied, not a generic default.
iManage's API lets other systems read and write workspace, document, and matter metadata, and a handful of prebuilt integrations already run on top of it, including links to Salesforce, DocuSign, and SharePoint. We don't sell or administer iManage. We build the custom work that picks up wherever those prebuilt connectors leave off.
iManage's API exposes matters, documents, versions, and the metadata tied to each one, client, matter, author, and more, to any system built to authenticate against it. That's the same layer the ready-made integrations run on.
Some of those integrations are real and already built. A DocuSign connection lets a document move from iManage into a signing flow and back. A Salesforce integration links an iManage workspace to the matching Salesforce record. SharePoint and Office 365 connections let staff work on iManage documents from inside Microsoft's own apps.
Each one solves a general case well. None of them know your firm's specific matter-numbering convention, your billing triggers, or what should happen the moment a document comes back signed.
A connector will move a document or sync a field. It won't decide that a signed contract should open a billing task in three systems, or that a new Salesforce opportunity should spin up an iManage workspace with the right security settings already applied.
That's where custom integration work against the iManage API comes in. If something a firm wants genuinely isn't exposed through the API, we'll say so rather than force a fragile workaround.
A new matter in your practice management system creates the matching iManage workspace with your firm's own metadata and security settings already applied, not a generic default.
A document coming back from DocuSign and landing in iManage as executed fires a billing entry or a task somewhere else, instead of sitting there until someone opens it.
A Salesforce field that won't map right, a SharePoint sync that only half works: tell us what it is and we'll look at what the API can actually do for it.
Tell us what's not connecting, a Salesforce workspace that needs more than the standard integration gives you, a records deadline that depends on someone remembering to check. We'll look at what iManage's API actually supports before anyone considers a workaround. And if iManage isn't where the friction lives, that's fine too; manual re-entry shows up in plenty of other corners of a firm and we'll look at those just as readily.
Let's talk →Yes, a Salesforce integration exists that links iManage workspaces to matching Salesforce records. It covers the general case; firms with their own field mapping or workspace rules usually need custom work on top of it.
Yes. Documents can move from iManage into a DocuSign signing flow and come back filed as executed, which is exactly the kind of event we commonly build further automation around.
Yes, integrations exist that let people work on iManage documents from inside SharePoint and Microsoft's Office apps, so staff aren't forced into a separate iManage window for every edit.
Yes, iManage publishes API documentation for developers and integration partners building against it. That's the reference custom integrations, including the ones we build, come from.
A development kit iManage provides for building applications and integrations against its platform, aimed at developers rather than end users configuring the system through its normal interface.