Technical FAQs

Question

Why am I receiving a 500 error when making a Viewing Session PUT request?

Answer

This issue can occur if you forget to prefix the {viewingSessionId} portion of the URL with u, or if you simply request an invalid {viewingSessionId} in the call.

For example, the PUT call should look like the following:

PUT /ViewingSession/u{viewingSessionId}/SourceFile

For more information on syntax and other API calls related to Viewing sessions, please see:

https://help.accusoft.com/PrizmDoc/latest/HTML/webframe.html#pas-viewing-sessions.html

Question

We have just applied the solution name and key for our cloud license, however, when trying to start the Prizm service, it fails to start.
What could be causing this issue?

Answer

There are a few reasons why this would occur:

  1. The server does not have internet access. Internet access is required for cloud licensing to connect to an S3 bucket.
  2. The server does not have proper rights to access the S3 bucket configured. Please verify the rights to the S3 bucket. Information can be found here: https://help.accusoft.com/PrizmDoc/latest/HTML/prizmdoc-cloud-license-and-aws.html
  3. Verify the solution name is spelled properly. The solution name is case-sensitive.
  4. Verify that the name of the S3 bucket entered in the customer portal matches your actual S3 bucket name. The S3 bucket name is case-sensitive.

Adding document viewing features to an application can be a challenge. Although there are many open source options available, finding a suitable ASP.NET document viewer or .NET image viewer that provides the right level of flexibility and functionality often requires a more specialized solution. Fortunately, .NET developers have good options when the time comes to integrate document viewing into their software, which helps them to focus on other application features.

The API Document Solution

Rather than building a dedicated viewer within their .NET application, many developers instead turn to an HTML5 viewer integration that uses REST APIs for their document needs. Since these viewers work within the web browser and can support any programming language, they provide the right balance of versatility and performance for most software applications. An HTML5 document viewer ensures a consistent viewing experience across multiple software platforms and browsers used within an enterprise environment.

Of course, if all an application needed to do was view files, it could simply use one of many open-source solutions. The problem is that these viewers typically only view one type of file, which means that the application also needs the ability to convert files into different formats. Depending upon the library in question, this could quickly escalate into a code-heavy solution that bogs down application performance and introduces multiple security vulnerabilities. If poor conversion tools are put in place, there’s also a strong likelihood that documents will not render accurately.

An HTML5 viewer with the right APIs can easily overcome these document management challenges for a .NET application. Conversion, annotation, comparison, and redaction features can all be integrated as part of a comprehensive viewing framework that doesn’t require developers to build anything from scratch or rely upon intrusive plugins that create risky dependencies.

How Accusoft APIs Enhance Your .NET Application

Accusoft’s PrizmDoc Viewer was designed to provide a broad range of document processing capabilities in addition to its core HTML5 viewing features. Once integrated into a .NET application, it allows developers to deploy REST API calls to convert files into new formats, split and merge documents, create page thumbnails, markup documents, and perform high-volume text searches. As an HTML5 viewer, PrizmDoc Viewer can deliver all of that functionality right within the browser rather than resorting to external applications.

The primary advantage of REST APIs is that they can be used from any programming language, so they don’t have to be custom-built to serve as an ASP.NET document viewer. That versatility does come with a tradeoff, however. Processes like uploading files, converting them, and then downloading outputs all require a series of HTTP requests. While this isn’t a particularly difficult process, it is slightly more resource-intensive than a solution built using the same programming language as the application. 

That’s why we developed a .NET SDK library that wraps around the server-related functions of PrizmDoc Viewer. Available for both .NET Core and .NET Framework, this SDK library wraps around the server’s REST APIs to make it easier to utilize server functionality in .NET applications.

For .NET developers looking for a better way to view and process documents, the PrizmDoc .NET SDK can help them access conversion, redaction, and annotation features without compromising the performance of their .NET applications.

Getting Started with PrizmDoc .NET SDK

In order to implement the .NET wrapper, developers just need to follow a few simple steps. 

1. Gain Access to a PrizmDoc Server Deployment

There are two ways to access PrizmDoc Server, which will allow you to carry out a variety of document processing functions. You can host a server on-premises as part of a PrizmDoc Viewer integration or sign up for a PrizmDoc Cloud account to use Accusoft’s cloud-hosted deployment.

2. Add the PrizmDoc Server .NET SDK Package

Next, download the free, open source .NET SDK library from NuGet or GitHub and add it to your application project.

dotnet add package Accusoft.PrizmDocServerSDK

 

3. Create a new PrizmDocServerClient

Once the .NET wrapper is in place, it’s time to construct a new PrizmDocServerClient and connect it to the server.

For a self-hosted PrizmDoc Server that’s part of a PrizmDoc Viewer deployment, the base URL is all that’s needed:

var prizmDocServer = new PrizmDocServerClient("http://localhost:18681");

 

If the you’re using PrizmDoc Cloud, you’ll need to provide the base URL along with your API key:  

var prizmDocServer = new PrizmDocServerClient("https://api.accusoft.com", "YOUR_API_KEY");

 

4. Begin Document Processing

Now that everything is in place, you can start processing and viewing documents within your .NET application. Our How To Guides provide some examples of common use cases, and you can also turn to the API Reference for additional guidance and information.

Get the Document Viewing Features Your .NET Application Needs

Accusoft’s PrizmDoc Viewer delivers the versatile HTML5 viewing capabilities that can set your .NET application apart from the competition. Thanks to the PrizmDoc Server .NET SDK wrapper, you can leverage the power of our REST APIs without needing to build out a customized viewing solution from the ground up.

Find out how easily you can manage your document needs with PrizmDoc Viewer’s browser-based functionality today. Sign up for a free trial to test our HTML5-powered viewer in your .NET environment.

The year was 1996. Dot-com was booming, Y2K loomed on the horizon, and Australia-based Outback Imaging needed adaptable software development toolkits (SDKs) to prototype a desktop imaging application capable of pushing scanned documents into popular EDRM systems without the need for manual import tools. They also needed a custom-built TWAIN UI to unify the customer experience without locking them into specific scanner brands.

In what one can only imagine was a montage of classic search engine queries, the company sourced three likely candidates. Within six months, they found their front runner was Accusoft, and the partnership began.

In 2003, they rolled out their first commercial product, EzeScan. Today, the product does more than just document imaging — EzeScan now offers server-based automated task processing and browser-based document workflow and approval capable through Robotic Task Automation (RTA) 24/7/365 with no human intervention.

With B2B churn rates rising, Medium notes that “regardless of industry, customer retention is often many leaders’ main strategic objective given today’s highly competitive landscape.” What’s the secret to Accusoft and EzeScan’s ongoing, mutually beneficial relationship?

Thankfully, the answer isn’t a vague, inspirational quote. In fact, it’s possible to debrief this age-defying agreement with three key characteristics including scalability, simplicity, and support.

Document Imaging at Scale

For EzeScan to evolve from a digital imaging application to a document transformation powerhouse, Outback needed toolkits that operate seamlessly within a Microsoft IDE, enables easy deployment on Windows, and includes superior code examples and documentation.

After four months of building three prototypes, Outback selected Accusoft SDKs to help jumpstart EzeScan R&D and embrace the need for digital transformation at scale. Today, the company leverages Accusoft’s TWAIN, ISIS, and PDF tools along with their OCR, MICR, and ICR search engines to drive continual evolution in their application.

Avoiding Technical Debt

Outback now supplies software solutions to a global network of customers, enabling them to both “go digital” and leverage their digital information in a more meaningful way. But developing this worldwide reputation for quality components and actionable results required an SDK foundation that was easy to implement and simple to use.

Accusoft offered the ideal solution to their problem. Toolkits that are customizable, incredibly simple to integrate, and work as expected. For Outback, this meant the ability to easily test and maintain new code without worrying about technical debt building up behind the design team as they innovate.

You Need It? You Got It

As noted by the Harvard Business Review, responsiveness plays a critical role in the strength and stability of B2B relationships. Without ongoing, committed support for software and toolkits organizations often have no choice but to shift suppliers or run the risk of losing what they’ve built.

Support is an integral component of the Accusoft and Outback’s relationship. While problems rarely occur, when they do, these issues are prioritized and quickly remediated. The result? Both businesses come out ahead. B2B relationships rely on scalability, simplicity and support to stay afloat. Now in its 23rd year, the Outback and Accusoft partnership has never been stronger.

On Thursday, May 30, 2019, Accusoft hosted the Node.js meetup group at the East Annex Technology Center in Tampa, Florida. The presentation was led by two Accusoft employees: Charlie Davis, Software Engineer III and Shayne Fitzgerald, Software Engineer II.

With a great group of novice to advanced developers in attendance, the meetup started with networking and snacks. “It’s a great opportunity for developers to meet other professionals from their area and learn what’s happening in Tampa dev,” says Eric Gee, Software Development Manager at Accusoft.

The presentation began with a demonstration on how to set up a node project that uses native modules. Building from this foundation, the presenters provided performance comparisons of executing a program as a native module, a child process, or a multi-threaded node program.

Davis covered a variety of topics including Node.js worker threads, child processes, and more. Some high-level takeaways include:

  • Node.js is fantastic for i/o related work (e.g. handling http requests, reading/writing files from a file system, etc.) but not so great at handling cpu-intensive tasks (e.g. complex computations, cpu-bound work, etc.)
  • Worker threads are a new “experimental” addition to Node 12 that are being touted as a way to be able to do cpu-intensive tasks in node with better performance.
  • The reality is that worker threads only provide a marginal performance increase over existing Node constructs like forking a child process.
  • A developer that cares about performance should really choose to not perform their cpu-intensive computation in Node at all but rather execute a C++ or other native program from a Node context instead.
  • They can do this by executing a C++ program in a child process or by building a C++ add-on in Node

“To sum it up, developers need to know what the strengths and weaknesses of their tools are, and then choose the correct tool for the job,” Davis summarizes. “You wouldn’t use a hammer to saw wood. You might be able to duct tape a knife to the back of your hammer, but you should really just use a saw.”

The exploration continued with Shayne Fitzgerald’s take on which approaches make the most sense for a given set of use cases. In this portion of the presentation, Fitzgerald emphasized: “Node.js is just one tool in a developer’s toolset. By using native add-ons we can leverage not only JavaScript but also native-compiled code to deliver high performance and quality software. You don’t need to be a C++ master to get that value either, as the native API is simple enough to understand.”

The duo put a smile on everyone’s face as they presented the content. Everyone left with new information and like-minded professional connections. “We had a great turnout of beginner to intermediate developers from the Node.js Tampa community. Those who attended will hopefully be able to more effectively write performance enhancements for their node applications,” says Davis.

Node.js is an open group dedicated to developers that are interested in learning more about Node.js and related coding techniques. The group is open to anyone that’s interested with no experience necessary. Keep your eye out for the next Node.js meetup on meetup.com.

Technology change is coming to the legal industry. As noted by a recent IT Pro Portal survey, 60 percent of legal staff “would be happy to work alongside robotic technology if it meant fewer manual processes,” while the American Bar Association found that 49 percent of lawyers are now using legal analytics to improve service delivery.

Staffing firm Robert Half puts it simply. To enhance client service and efficacy, “law firms will take a more proactive approach to technology.” But as the tech market diversifies, new challenges emerge. Companies need to find best-fit solutions that both maximize digital budgets and deliver ROI. Let’s break down the coming “C” change with a look at three top-performing technology trends for 2020.


   Cultural Change 

Digital transformation has been making its way into the legal industry, but the trend toward broader technology adoption and integration has created a personnel plateau. While new solutions help streamline key processes such as document redaction, forms data capture, and document automation, they’re not enough in isolation. Steady gains demand technology deployments that align with existing process frameworks to encourage meaningful, cultural change.

Consider document automation. As noted by Law.com, while 2019 saw increased legal spending on automated contract review and document automation solutions, spending alone doesn’t guarantee success. Firms need tools capable of integration with current legal applications, allowing teams to leverage existing frameworks. The result? Cultural change that comes from within rather than being imposed from without.


    Communication and Collaboration

As noted by Forbes, while the legal industry has often focused on “silver bullets” to solve technology problems at scale, firms have been reticent to deploy solutions focused on existing process improvement. Case in point? Communication and collaboration. 

Law firms are expected to increase the availability of remote work options. As clients expect personalized, prompt, and digitally-proficient service, 2020 requires the adoption of technology solutions and best practices that enable communication anywhere, anytime.

In practice, this means deploying tools that allow staff to view multiple file types in a single browser, quickly add comments or annotations, and covert documents on-demand to encourage collaboration without compromising risk management. With documents kept in your application ecosystem, staff won’t need to leverage outside tools — such as email — that introduce potential compliance issues.


   Casework Consolidation

The third “C” is consolidation. Is it coming to legal firms this year? We think so. Here’s why. According to The Balance, ongoing amendments to the Federal Rules of Civil Procedure are changing the landscape of litigation as electronically stored information (ESI) such as emails, text messages, mixed media, and mobile data all become fair game in document discovery — and critical to successful casework.

The result? Law firms need technology solutions that both empower eDiscovery processes and consolidate casework efforts, making it easier to find what they’re looking for — faster — and ensure effective access control. From full-text, keyword-driven support for document searches to full-featured digital rights management (DRM), firms need all-in-one eDiscovery solutions that are easy to integrate, simple to customize, and help consolidate casework under a single search solution.

 

Accusoft Forms API v1.0 is a set of classes that encapsulates the implementation required to connect FormSuite components together to build a forms processing application. In previous releases of FormSuite, you had to code against the APIs of the components of FormSuite to build a forms processing solution. This could include coding against the APIs of FormFix, FormDirector, SmartZone OCR and ICR, ScanFix Xpress, and possibly other components sold separately from FormSuite. Furthermore, to maximize the performance of these components, you had to understand the best practice use of these APIs. Forms API removes this burden and implements a standard forms processing workflow using best practices of Accusoft’s form processing and recognition components.

We provide the API as both source code and compiled binaries (which will be used by FormAssist and the Forms Processing Server sample). The motivation to ship as source code is to allow you to reuse the API in a solution that uses an alternative forms processing workflow or other recognition engines.

Limitations

Since the API does not completely wrap the FormSuite API, you’ll still have to interact with result objects from the FormSuite components. Also, you can optionally load and save form sets and form definitions using the FormDirector component, or it can leave all of this functionality up to the Forms API.

The Accusoft Forms API will only support forms processing functionality. It does not support any form set creation or editing functionality. Furthermore, the processing functionality supports one forms processing workflow, which is the standard workflow implemented by FormAssist in previous releases of FormSuite. The Accusoft Forms API encapsulates the usage of all the FormSuite components.

The Forms API wraps the details of interacting with the FormSuite components to make your forms processing application development easier.

We provide two demonstration samples to guide you in using the Forms API:

Automating your forms processing using FormSuite has two main steps:

  1. FormSet Creation – involves selection of image files to be used as form templates, and definitions for processing OCR, ICR, OMR, Barcode, or Clip fields for each template image. The FormAssist application makes it easy to specify processing instructions for each individual field.
  2. Filled Form Processing – lets you select one or more filled image files for processing, and then processes the images based on the instructions provided. The processing steps include image enhancements, form identification (matching the input image to a form template), form alignment to the template, and processing of each defined field, including OCR, ICR, OMR, Barcode, and image clips.

The individual forms processing activities may be represented by the following illustration:
Forms Processing Overview

Of these main two steps, FormAssist does both. But, the Forms API and the Forms Processing Server only perform filled form processing. They don’t assist in form set creation. So, you should still use FormAssist to do the form set creation steps.

FormAssist and the Forms Processing Server are primarily designed for demonstrating the underlying technologies; they are not production level applications. However, customers use these demonstration programs to create and test form sets for use in their business processes. Some customers use the C# source code as a foundation for their form set creation process or their production workflow, while others use FormAssist or the Forms Processing Server as their primary form set creation and processing applications.

Forms Processing Workflow

The Processing workflow designed by Accusoft represents one of many possible forms processing workflows.
The following steps describe this process:

  1. Prior to processing filled forms, you can use the FormAssist application to create form sets.
  2. Then, process the forms using either the Forms Processing Server or FormAssist.

So now you have a good idea of how the Forms API can help you in developing your forms processing workflows. For more in-depth information such as FormSet creation and processing, image processing, and results generation, visit the complete Forms API documentation. Have questions? Drop us a line at marketing@accusoft.com or leave a comment below.


The PrizmDoc™ e-Signer supports filling out forms created using the PrizmDoc™ Template Designer, demonstrated here. Using the e-Signer, form fields can be filled out manually, filled out programmatically, or pre-populated with default values.

Once the fields are filled out, the user can click the Download Signed Form button to download a PDF with the filled in data. When this button is pressed, the e-Signer uses the PrizmDoc Server “MarkupBurner” API to “burn” the data into the document.

But what if you already have all of your user’s data, and you want to skip straight to burning the data into the document without loading the form into the e-Signer? In this post, I will outline how to create a Node.js service to do so.

The example code and instructions for running the service are available in the Accusoft prizmdoc-form-burner-example GitHub repository.

1. Handle Routing Form Burner GET Requests

This service will handle routing GET requests for burning data into a form, and this initial step sets up the route handling.

For this example, you will need to put your form definition file (or files) in a folder named “FormDefinitions” along with a form data file (with the same name but with a “data.json” file extension). Your form data file must contain key-value pairs, where each key is a form field ID and each value is the value to use to fill in the field. For example:

{
  "Text1": "Doe",
  "Text2": "John"
}

The corresponding form document will need to be put into a folder named “Documents”.

You will need to have Node.js and PrizmDoc Server installed. As an alternative to having PrizmDoc Server installed, you could connect to PrizmDoc Cloud.

Use npm to install express and axios. Express will be used to listen on port 3001 and route a GET request for a “form burner,” as shown below. Axios will be used to make http requests to PrizmDoc Server (in step 3).

Create a main.js file and, as shown below, require express, axios, and fs (which will be used to load a form data file, as shown below, as well as the form document and form definition file).

const express = require('express');
const axios = require('axios');
const app = express();
const fs = require('fs');

// PrizmDoc Server must be installed to use this.
const host = 'http://localhost:18681';

// Use the following instead to use PrizmDoc Cloud.
// const host = 'https://api.accusoft.com';
const apiKey = 'YOUR_API_KEY';

app.get('/formBurner/:id', function (req, res) {
  // This example uses the field value provided in the data.json file in the FormDefinitions folder.
  // You can update the code to instead load the data from elsewhere, such as a database.
  fs.readFile(`${__dirname}/FormDefinitions/${req.params.id}.data.json`, 'utf8', function (err, data) {
    const fieldValues = !err ? JSON.parse(data) : {};
    // See step 2 for the implementation of convertForm.
    convertForm(fieldValues, req.params.id, res);
  });
});

var server = app.listen(3001, () => console.log('listening on port 3001'));

2. Convert Each Form Field to Markup

The PrizmDoc Server MarkupBurner API takes markup JSON as input. It is necessary to convert each form field to the proper markup format. The convertForm method below opens the form definition file with the specified form definition ID and converts each field to markup, using the specified field values to fill in the fields. The markup is then burned into the form document (see step 3).

This example only demonstrates converting text fields but could be updated to also convert other field types, such as signatures and checkboxes.

const convertForm = (fieldValues, formDefinitionId, res) => {
  fs.readFile(`${__dirname}/FormDefinitions/${formDefinitionId}.json`, 'utf8', function (err, data) {
    const formDefinition = JSON.parse(data);
    let marks = [];

    const globalFontName = (formDefinition.globalSettings && formDefinition.globalSettings.fontName) || 'Fira Sans';
    const globalFontColor = (formDefinition.globalSettings && formDefinition.globalSettings.fontColor) || '#000000';

    formDefinition.formData.forEach(field => {
      if (field.template === 'TextTemplate') {
        let mark = {};
        if (field.multiline) {
          mark.type = 'TextAreaSignature';
          mark.maxFontSize = field.fontSize || 8;
          mark.fontStyle = [];
        } else {
          mark.type = 'TextInputSignature';
        }
        mark.uid = field.fieldId;
        mark.interactionMode = 'Full';
        mark.creationDateTime = '2019-06-25T19:28:13.396Z';
        mark.modificationDateTime = '2019-06-25T19:28:13.396Z';
        mark.mask = null;
        mark.maxLength = 0;
        mark.rectangle = { x: field.rectangle.x, y: field.rectangle.y, width: field.rectangle.width, height: field.rectangle.height };
        mark.pageData = { width: field.pageData.width, height: field.pageData.height };
        mark.pageNumber = field.pageNumber;
        mark.fontColor = (field.fontColor === 'UseGlobalFontColorSetting') ? globalFontColor : field.fontColor;
        mark.fontName = (field.fontName === 'UseGlobalFontNameSetting') ? globalFontName : field.fontName;
        mark.horizontalAlignment = field.horizontalAlignment ? (field.horizontalAlignment.charAt(0).toUpperCase() + field.horizontalAlignment.slice(1)) : 'Left';
        // If a field value is not provided, this example uses the value of "example".
        mark.text = (fieldValues[field.fieldId] !== undefined) ? fieldValues[field.fieldId] : 'example';
        marks.push(mark);
      }
    });

    // See step 3 for the implementation of burnForm.
    burnForm(marks, formDefinition.templateDocumentId, res);
  });
};

3. Burn the Markup into the Form

Use the PrizmDoc Server MarkupBurner API to burn the markup into the form document, as shown below. The burned document is returned in the response to the formBurner request.

const burnForm = async (marks, documentName, res) => {
  const { affinityToken, markupFileId } = await postMarkup(marks);
  console.log(`markupFileId: ${markupFileId}`);
  const documentFileId = await postDocument(documentName, affinityToken);
  console.log(`documentFileId: ${documentFileId}`);
  const processId = await postBurner(documentFileId, markupFileId, affinityToken);
  console.log(`processId: ${processId}`);
  const burnedDocumentFileId = await getBurner(processId, affinityToken);
  console.log(`burnedDocumentFileId: ${burnedDocumentFileId}`);
  const burnedDocument = await getBurnedDocument(burnedDocumentFileId, documentName, affinityToken);
  res.end(burnedDocument, 'binary');
};

First, the markup and form document are uploaded to PrizmDoc Server as “work files”.

const postMarkup = async marks => {
  const response = await axios({
    url: `${host}/PCCIS/V1/WorkFile?FileExtension=json`,
    data: {
      marks
    },
    method: 'POST',
    headers: {
      'Content-Type': 'octet-stream',
      'acs-api-key': apiKey
    }
  });

  return { markupFileId: response.data.fileId, affinityToken: response.data.affinityToken };
};

const postDocument = async (documentName, affinityToken) => {
  const response = await axios({
    url: `${host}/PCCIS/V1/WorkFile`,
    data: fs.readFileSync(__dirname + '/Documents/' + documentName),
    method: 'POST',
    headers: {
      'Content-Type': 'octet-stream',
      'acs-api-key': apiKey,
      'Accusoft-Affinity-Token': affinityToken || ''
    }
  });

  return response.data.fileId;
};

Next, a markup burner is created, using the uploaded markup and form document as input.

const postBurner = async (documentFileId, markupFileId, affinityToken) => {
  const response = await axios({
    url: `${host}/PCCIS/V1/MarkupBurner`,
    data: {
      'input': {
        'documentFileId': documentFileId,
        'markupFileId': markupFileId
      }
    },
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'acs-api-key': apiKey,
      'Accusoft-Affinity-Token': affinityToken || ''
    }
  });

  return response.data.processId;
};

Then, the status of the markup burner is checked until it’s completed.

const sleep = (ms) => {
  return new Promise(resolve => setTimeout(resolve, ms));
};

const getBurner = async (processId, affinityToken) => {
  const response = await axios({
    url: `${host}/PCCIS/V1/MarkupBurner/${processId}`,
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
      'acs-api-key': apiKey,
      'Accusoft-Affinity-Token': affinityToken || ''
    }
  });

  console.log(`MarkupBurner percentComplete: ${response.data.percentComplete}`);

  if (response.data.state === 'complete') {
    return response.data.output.documentFileId;
  }

  if (response.data.state === 'error') {
    return;
  }

  await sleep(1000);
  return getBurner(processId, affinityToken);
};

Finally, the burned document is retrieved.

const getBurnedDocument = async (documentFileId, documentName, affinityToken) => {
  const response = await axios({
    url: `${host}/PCCIS/V1/WorkFile/${documentFileId}`,
    method: 'GET',
    responseType: 'arraybuffer',
    headers: {
      'Content-Type': 'application/pdf',
      'acs-api-key': apiKey,
      'Accusoft-Affinity-Token': affinityToken || ''
    }
  });

  // Uncomment the line below to save the burned document to disk.
  // fs.writeFileSync(`${__dirname}/${documentName}_burned.pdf`, response.data);

  return response.data;
};

Using the Service

Once you’ve followed these steps, you can use the service to directly burn your user data into your forms.

Run “npm install” and then “node main.js” to run the service. Then make a GET request to http://localhost:3001/formBurner/{your-form-id} to get a PDF of your form with filled data burned in.

The example code and more information are available in the Accusoft prizmdoc-form-burner-example GitHub repository.

Alex Kondratrov

Jared Jacoby, Software Engineer, PrizmDoc

Jared Jacoby has worked at Accusoft since 2005. Starting as a support engineer and promoted to a software engineer a couple years later, Jared has worked on numerous Accusoft products including the ImagXpress family, ImageGear, and PrizmDoc. He graduated from the University of Florida in 2004 with a degree in Computer Science. In his spare time, Jared enjoys playing board games, music, and writing.

The legal tech landscape is experiencing remarkable growth. In 2024, legal tech companies raised nearly $5 billion—that’s a 47% increase from 2023. This surge in funding represents the industry’s growing appetite for innovation.

Technology is reshaping how legal professionals work and how software providers meet their needs. Artificial intelligence (AI) and automation are leading the charge, creating more opportunities for innovation and efficiency.

For independent software vendors (ISVs) looking to improve their ECM applications, these trends point to exciting opportunities. Those who jump on board will play a role in shaping the future of legal service delivery.

Let’s take a look at some key legal tech trends we expect to see reshape ECM offerings this year.

Trend 1: AI-Powered Document Processing and Automation

The legal industry’s adoption of AI-powered document processing has advanced beyond simple OCR and basic automation. Sophisticated AI algorithms are shifting how legal professionals handle, analyze, and manage documents. This shift is unlocking deeper insights and enabling more strategic decision-making.

One critical capability for legal enterprise content management: intelligent document classification and indexing. These AI systems can automatically categorize incoming documents. They can also extract key metadata and route files to the appropriate workflows with minimal human intervention. For many law firms, this means greater document classification accuracy.

Automated redaction has made equally impressive strides. Today’s AI systems can identify and redact sensitive information across multiple document types—even handwritten notes and complex tables. Beyond recognizing patterns, they understand the context of information. Automated redaction reduces the risk of accidental data exposure, saving law firms countless hours of manual review.

Contract analysis and review have seen some of the most dramatic transformations. AI systems have the power to analyze hundreds of contracts simultaneously. They can identify potential risks, inconsistencies, and non-standard clauses. AI is opening doors for software vendors to add powerful contract analytics to their existing platforms.

These capabilities provide significant time and cost savings. Legal teams can compare contracts against standard templates, flag unusual terms, and provide risk scoring in real time—faster and more accurately than ever before.

What’s Coming in 2025?

  • More integration with multimodal AI so AI systems can process and analyze documents with images, diagrams, and tables
  • Real-time collaboration features enhanced by AI that allow legal teams to review documents as AI provides instant insights
  • Domain-specific AI models trained on legal documents to improve the accuracy and reliability of automated document processing

Trend 2: Enhanced Document Security and Compliance

As law firms move more operations online, their security and compliance needs have changed. Legal tech providers must build solutions that not only protect sensitive documents, but also keep pace with evolving compliance requirements.

Zero-trust architecture is the norm for document security in legal applications. Today’s solutions need robust access controls that check every user interaction, no matter where or how people work. This means building systems that continuously authenticate users, track document access, and respond to suspicious activities.

Managing documents throughout their lifecycle has evolved to include automated retention policies and audit trails. Legal professionals need solutions that can track and manage documents from creation through disposal. These systems should be able to handle different document types while maintaining detailed records of every view, edit, and share.

What’s Coming in 2025?

  • Greater sophistication with regulatory AI integration, including security systems that adapt to new compliance requirements
  • Blockchain-based document verification to help maintain chain of custody and regulatory compliance
  • Advanced biometric authentication with multiple authenticators for highly sensitive legal documents

Trend 3: Cloud-Based ECM and Collaboration

Law firms are quickly moving to cloud-based document management and collaboration platforms. As a result, many ISVs are reimagining their solutions to meet the demands of distributed legal teams.

Hybrid cloud architectures have emerged as the preferred approach for legal operations. They combine the flexibility of public cloud services while offering the control of private infrastructure. ISVs are now expected to deliver solutions that can seamlessly manage documents across hybrid environments. These solutions must automatically optimize storage and access based on document sensitivity, compliance requirements, and usage patterns.

Real-time collaboration capabilities are non-negotiable for legal ECM solutions. Users demand simultaneous document editing, version control, and change tracking with millisecond precision. Many software vendors are integrating conflict resolution systems that can handle multiple users working on complex legal documents while maintaining document integrity.

A solution’s ability to work well with other legal tools can make or break the solution. ISVs must provide robust APIs and pre-built connectors that enable their solutions to play nicely with other legal tech tools—from e-signature platforms to court filing systems.

What’s Coming in 2025?

  • Edge computing integration enabling faster document processing and reduced latency for distributed teams
  • Microservices architecture adoption for more flexible, scalable ECM solutions
  • Advanced document versioning systems for more complex collaboration scenarios

Trend 4: Streamlined eDiscovery Workflows

As legal professionals handle higher volumes of complex data, eDiscovery has transformed. Early case assessment has become more sophisticated thanks to advanced analytics and AI. Modern eDiscovery platforms must now handle not only traditional document types, but also chat logs, social media content, IoT data, and various forms of digital communication. ISVs are developing solutions to analyze these diverse data sources, providing early insights into case merits and potential discovery scope.

Predictive coding and technology-assisted review (TAR) have also evolved beyond basic document classification. Contemporary solutions incorporate machine learning models that can understand context, identify patterns across data sources, and adapt to different legal practice areas. For software vendors, this means ensuring their platforms provide transparent AI decisions while maintaining defensible discovery processes that can stand up to court scrutiny.

What’s Coming in 2025?

  • AI-driven early case assessment tools for helping legal teams make more informed decisions about litigation strategy and resource allocation
  • Automated privilege review for identifying potentially privileged communications across languages and communication channels
  • Real-time cost analytics and prediction offering detailed insights into discovery costs as they occur and predicting future expenses based on case patterns and complexity

The Bottom Line: Software Vendors Should Be Ready to Embrace New Opportunities

Staying ahead of these trends isn’t just about maintaining market position. Legal tech ISVs who integrate advancing technologies into their solutions will be better positioned to meet the demands of legal professionals—and that’s no small feat.

Creating modern legal tech solutions takes time and resources, especially when it comes to AI and machine learning. Software vendors will also have to stay well-versed in the latest updates and evolving standards to maintain compatibility.

But the opportunities far outweigh the costs. Software vendors have a unique opportunity to create modular, scalable platforms that can serve law firms of various sizes. They can introduce premium features powered by advanced AI capabilities.

The good news: You don’t have to tackle it all alone. Accusoft’s comprehensive suite of document processing, viewing, and imaging solutions can help you enhance your application with the powerful features legal professionals need. Our SDKs and APIs provide the building blocks you need to create cutting-edge legal tech solutions, from secure document viewing, redaction, and annotation to AI-assisted tools.

Ready to gain a competitive edge in the legal software market? Explore our solutions for legal tech ISVs today.

Question

Is it possible to automatically annotate a document, similar to the Auto-Redaction feature, using PrizmDoc?

Answer

An auto-annotation feature isn’t an out-of-the-box feature but with some work, it can be done. This would involve creating a searchTask and using the information from it to programmatically create XML markup that can be used in the MarkupBurner.

To do this you would need to create a searchTask for the pattern you would like to annotate. You can then get the results of the searchTask as JSON which will contain all occurrences of that pattern/search. Each search result will include the selected text, the page on which it occurs, the starting index of the result, and the dimensions and coordinates of the bounding rectangles for that search result.

All this information can be used to construct the markup XML to add the annotations with the markup burner.

Once you have constructed the XML you would post to the MarkupBurner with the XML as the body to burn the document.