Docmosis Reviews

We are a B2B cloud service provider offering SaaS solutions to the UK energy industry. Our billing products require various forms of end customer communication. If our customer does not have their own solution in place for rendering documents, we recommend Docmosis.

Our software operates in a serverless (AWS Lambda) environment so a web service for this was clearly important and inline with our technology strategy.

We use the product for two main functions:

1. PDF rendering of bills and other documentation aimed at our customer's customers. Bills in particular can be complex documents that also need to be presented clearly, smartly, and on brand.
2. HTML rendering for emails.

Having a robust, simple, cost-effective rendering solution integrated into our own products increases our attractiveness to customers. It is also vital to our architecture that the software follows our cloud strategy.

Our customers benefit by being able to be extremely agile in changing the flat text in any of their communications. Their operations are made easier by having up-to-date messaging. 

During the COVID-19 crisis they were able to author and implement vital messaging to their customers in a single day.

For startups, having a cost model that grows as they do is essential.

We mainly use the PDF rendering facility. The combination of the MS Word template and the passing of a JSON data object into a single simple REST API call that returns a PDF document is exactly what we required. 

The ability to embed, and dynamically repeat, templates within each other is a very simple yet extremely powerful tool.

The HTML rendering, in combination with our own AWS SES service, allows a very simple method of producing bespoke emails. 

The storage of templates within the product in a folder structure makes the rendering call simple and also allows for multiple environments to be catered for. 

Haven't investigated fully, but the HTML rendering could be a little more sympathetic to multidevices. Perhaps some options are available there. 

Although not a requirement at the moment, the ability to produce charts might be so for some customers. A solution, however simple, for this would be great. As it is not a requirement at present, we haven't fully investigated whether this may well be achievable one way or another. 

Version control and restricted access to some users for template editing could also be a useful addition.

One year.

Good. Not a single issue so far with thousands of documents. 

We don't have a concern for our many use cases, but they are primarily small documents. 

The integration works. Seems flexible about hitting band upper limits but always wise to model this as best you can.

On the single occasion that we used tech support, which was for an issue with our environment, they were very helpful.

They are flexible when discussing environments, pricing bands, etc.

Not for this exact scenario. 

Memory of setup was that it was straightforward with some good coding examples to supplement the documentation.

In-house.

Cloud and REST API models keep the setup costs low. 

Price bands are based on pages so ensure you have a good understanding of this if documents are of variable length. 

Did not formally evaluate multiple solutions. Selected preferred option on apparent ease of integration and cost, then trialed it successfully.

Our primary use case is to make it easier for HR teams to generate HR documents for employees via an intuitive user interface and in a few clicks. In this context, we need a document generation solution embedded within our product which allows us to generate documents from preconfigured document templates with a rich syntax (conditional sections, mathematical functions, date, and number). Data is then retrieved from the different HRISs and fetched with the document template in order to fill the generated document. 

The product is currently very complete and meets the majority of our use cases.

Globally, the ability to create document templates in several formats by using a rich syntax is simple and clear to understand. 

Our business is expanding internationally, as is Docmosis. So, we are facing new challenges such as internationalization. The next big challenge will be to offer even more date formats and numbers that cover the majority of countries. It will be to also think about features, such as number to text conversion, or the reverse which is currently only available in English but is in great demand by our international customers.

Our business is in a hypergrowth phase, and Docmosis not only provided us with a powerful library for document generation that has accompanied our growth, but also with amazing support during this transition. We had the pleasure of discussing with experts who perfectly mastered use cases of document generation, were able to provide us with their feedback, and who have been very reactive.

We had a limited homemade solution to generate documents based on Java technology which was not scalable at all.

It was easy for us to integrate this solution into our existing system. Our technical teams greatly appreciated the technical documentation provided and the reactivity of the support. This allowed us to be live in less than two weeks, which is a big challenge in the software world.

We integrated Docmosis Cloud service into our custom software application developed for medical analysis. We have been using Docmosis Cloud service for the past six years. We were able to generate complex detailed reports to display the results of medical testing. The reports have a complex layout with multiple table/header structures. The Docmosis template based approach was ideal to generate these reports and make any changes quickly. 

The Docmosis solution was ideal to handle our use case. To generate these same tabular formatted reports with a code-only solution would have taken a lot longer to implement than the Docmosis template based approach. Docmosis templates were easier to design as we were able to use Microsoft Word to create them. The templates made it easy to make any changes to reports and provided flexibility in our design approach. We were able to generate real-time multiple page PDF reports from our application, which were well-formatted. The process of adding any new report is also fairly simple with Docmosis Cloud service.

The features we found most useful for our application are: 

• Template based approach
• Cloud hosted solution
• Flexibility to update templates
• Easy rendering of templates. 

Adding new templates is also simple with the cloud based service. Templates are just Microsoft Word documents, so there is no need to learn other templating. 

It would be great to have improved diagnostic and debugging tools. When report templates are complex, sometimes any minor modification needs to be thoroughly tested to ensure that it does not disrupt a previously designed template. 

Six years.

Docmosis has good customer support and plenty of documentation available along with code samples which helped us to implement the REST API easily. Also, we were able to get rendered reports in different available formats (PDF, HTML, text, etc.).

The new DWS3 cloud console looks great and user-friendly compared to the older DWS platform. It will be easy to track, manage, and upload templates with new DWS3 cloud console UI.

We found Docmosis Cloud service very easy to use and implement for our application reporting needs. 

Evac Guide is an online tool that allows organisations to create and manage all their workplace emergency planning documents in one place.

Initially, we did HTML web page to PDF conversions of documents and that proved to be a lot of work with hard coding. 

We persevered for 12 months until it got beyond a certain point. We just didn’t have the flexibility in the formatting that we required. Then we found Docmosis which can do the PDF conversions for us. Now, we don’t even look back at doing it any other way.

The transition to LibreOffice was pretty easy after working with Microsoft Office. As a non-tech person, I have been able to contribute to the formatting of our LibreOffice templates which saves the tech staff from getting bogged down doing all the work.

In total, we’ve got 17 templates with one fairly complex document template of at least 40 pages long which has a mixture of images, title pages and tables. By going down the path of using Docmosis with templates it’ll be a lot easier to maintain control and consistency than if it was done through HTML.

The process of setting up the cloud engine was a smooth process.

No, this was the first PDF converter engine we installed. We had done significant research prior to committing to Docmosis and we strongly believe this has paid off.

The technical support offered by the team at Docmosis has exceeded our expectations. We have a large template that demands performance to be converted, however, Docmosis were always available to assist us as required.

It allows us to develop and deliver highly-customized reports for our clients in ways that are generally pretty straightforward, flexible and easy to manage.

From an organizational standpoint, it's reduced our need for a developer to be involved in delivering customer reports for customers, so we don't need our development team, engineers, and software developers to customize reports for customers. It lowers cost and allows us to deliver customized reports faster than we could before.

It allows us to use MS Word with dynamic data population, which is a huge advantage.  Connecting to a cloud service also is a nice feature

It's still a bit complex to develop reports and because of that complexity, there are often mistakes that get made. If we get better debugging tools and better diagnostic tools, developing reports would be faster. That process is a bit slow right now.

It's been very stable.

We scaled it in dramatic ways, and it handled our scalability very well.

I would say that they are very proactive. They are very responsive and have been very helpful in solving problems when we have them.

We did, and still do. We've used another tool for a very long time and we're phasing it out. It's free and solves some, but not all, of our needs. But when we need to develop or generate a more highly-customized report, we use Docmosis. It allows us to use MS Word with dynamic data population, which is a huge advantage.

It's a powerful model for a couple of reasons. Being able to do report layouts allowed us to design reports without requiring developers needing good MS Word skills. Second, our customers provide us reports they've already designed in MSWord. All we need to do is to make them dynamic.

It allows documents to be designed without needing a developer or a web designer. Anybody who has expertise in Microsoft Word can do this kind of thing, or even the customer themselves could easily format the document to make changes. It's very powerful from that perspective, and I have never seen someone take this approach and do it well until I found Docmosis.

Generating PDF documents to serve as an audit trail capture of UI-driven accounting decisions.

After years of fighting with Actuate, Brio, and Crystal Reports to produce nicely formatted reports, we finally bailed and built our own reporting engine using Apache POI.  Unfortunately, POI did not lend itself well to complex, formatted PDF documents, much less allowing for WYSIWYG editing of report templates using familiar tools like Word.  Docmosis gave us the missing component for our document generation solution.

Auditability is a huge part of what we do. Part of that is generating an auditable track record that documents any decisions made along the way. All of the audit documents, all of the competitive sourcing documents, such as RFP, lease versus buy, proposals, and in some cases contract documents are generated out of LeaseAccelerator using Docmosis.

The number one thing for us is that the service has to be reliable and fast. When the user clicks a button, they don't see Docmosis, they see LeaseAccelerator. But they want that reply back quickly. That's exactly what we get with Docmosis. We get consistent, timely results. That is first and foremost the biggest value for us from Docmosis.

We've already briefly spoken with Docmosis, and we'll be pursuing this more - we are looking to take our intra-application monitoring to the next level. Really, we've embraced the DevOps philosophy and are trying to improve the monitoring, so it's not just your traditional up/down type monitoring but it's a more holistic system load, degeneration – where it may be performing uncharacteristically, not necessarily degraded or down, it's just the usage profile is atypical. Having that greater insight means being able to connect to Docmosis from a monitoring standpoint. Application to application to say “How many reports have we run in the last hour? What's the average performance time?" Those types of things. We're going to be looking for additional hooks we can use to monitor the Docmosis service as part of our offering, so that we've got a comprehensive view of system health.

During the AWS S3 outage last year, we did lose access to Docmosis for about 3-4 hours.  That's the only outage I can recall in over five years of using Docmosis.

The interesting challenge for us with lease management is that you don't get the types of volume and web traffic you see in more traditional SaaS applications. We're business to business and the nature of leasing is that, with the exception of month end, quarter end, and year end, a busy day is 100 to 150 users logged in at the same time. You just don't get the same volume of parallel traffic. That said, month end, quarter end, and year end, the system goes crazy. Everybody is trying to get transactions wrapped up before their budget runs out or they've just gotten the budget. Either way you see a surge in traffic, and at no point have we ever seen any impact on that from Docmosis when we get those surges. So to the extent that we need scalability, Docmosis has been more than satisfactory. I don't know that we're great witnesses to that because again, our definition of surge is not the typical web definition of surge.

We've had no complaints. The time zone difference is a little bit challenging. We're on the east coast of the US and they're in Australia, so it's about a 12 hour difference. It's generally handled by email but we've generally had everything resolved within one to two days. In the rare cases we've had an access issue, I think we had an issue maybe a year ago they updated a URL or something along those lines. That was resolved very quickly. We've been very pleased with the timeliness there.

We started with Actuate, moved to Crystal Reports, acquired a company that was using Brio. We've had the opportunity to try all three of the market leaders and to be bluntly honest, they’re all unsuitable. They are very burdensome in terms of designing and building new templates and none of them are using a format that we can easily hand off to our clients to say "Hey, if you need to tweak the legal boiler plate language, update a version tag, do it."

With Docmosis we're using Word based templates. It's child's play to have a client update that Word based template. As long as they're not messing with the data tags, they can change the boiler plate and the formatting all they like and they do.

It was very simple. I think we had it integrated into our system within a day and a half to three days, not just set up and using but actually integrated in. It was crazy simple.

In-house.

Positive.

I think it's reasonable. It's a tiered pricing structure, but we've found that the volumes that trip higher pricing align nicely with our own revenue growth.

It's absolutely fantastic. It's much easier to design your reports. It's fast. It's efficient. It's been fantastic for us. It comes highly recommended.

We are a Fintech company, and Docmosis is utilized in order to render loan and other financial documents.

It is a straight forward, cost effective, solution for rendering PDF documents. It saved us time and money due to its ease of use, Java api, and clear documentation.

The main benefit is exactly what it provides -- the ability to use word documents as templates, and therefore they can be edited by non-technical people.

Also, the placeholders with content work out really well with PDFs. The way we were doing this was cumbersome and this solution made all that easier. This was the motivation; it was difficult to update our PDF files. This looked like a much easier process in order make changes to our PDF documents.

Just one thing, and there is a way to get this done outside of the solution as currently I go to a third-party solution. I render multiple PDFs and then put them together into one document outside of Docmosis. Docmosis then provides the ability to include them, and that would almost work out for us except that we use some static content and, therefore, we would have no need to render them every time.

From what I have seen, it's been stable and has stayed up for five weeks without issue. I haven’t seen any instability so far.

I believe it’s scalable. We purchased a license that will allow us to put four converters out. We feel that it should work out pretty well, but if not, it’s easy to add more.

I have had very few questions, but the ones I have had have been answered very timely and they've answered all of the questions I needed needed answers to.

Previously, I used Adobe products, but price-wise this was out of the question.

It was much easier to implement than we thought. But because of the dependency on the open source/open office and having that installed and the fonts installed, it was a bit complex as we have to containerize everything. We have to make one and then build off of that container. It was a little complex, but you can manage it and it’s not bad. Overall the configuration was straightforward.

I work for a company that has a web app solution for tracking and managing leases - primarily equipment and hardware leases. Reporting is a major part of the lease tracking and data management offered by our system, and PDF documents that we generate using Docmosis are used on a daily basis by the clients.

Since our initial development, this feature has required very little maintenance. And when changes are requested, it is rather easy to change a Word document template and new staff can be quickly trained to modify a report.

A new report’s template creation is very often manipulation of a user’s layout of a report. A report can be ready in a day or less, once stored procedures are created as per sections in the report.

Compared to the original report-generating software, creation of templates in Docmosis - which can be as simple as a Word document - is the biggest plus for Docmosis. There is flexibility in laying out tables that is akin to UI front-end design.

The PDF output option offered by Docmosis is attractive to our clients since data cannot then readily be changed and manipulated.

The challenge in usage when we developed the reports four years ago was the limited logic that can be applied to manipulate and display data. That functionality was largely transferred over to the database layer in creating the data output that was to be displayed.

Development involves creating a template from user document requirements. In fact, the template in most cases can be a clone of the user document, with logic added for recursive or conditional data. We have been using a Word template for this purpose.

An XML template sheet maps the database output to the data placeholders in the Word template document. We have been using Oracle PL/SQL queries to retrieve formatted data for various sections of the templates.

Without doubt, the most valuable feature is the ability to operate and work within Microsoft Word, our default word editing program. When the rest of the organization is dealing with templates and Word format, it's nice to be able to use that as the system artifact that goes into generating the end results. We used to get our requirements in Word templates, then we'd have to do the costly conversion to XSLT templates, which was time-consuming and we never got it to look the way the business wanted it according to the Word template.

So the biggest the day-to-day benefits are working through a medium that can be universally used from requirements gathering all the way to a run-time and generating documents.

We're now live with one instance of generating documents, we're committed, and we've got the architecture and infrastructure to add more templates and migrate our old ones. We didn't realize it initially, but once we setup up our platform around Docmosis, we've registered new templates, merged data, and created PDFs.

When I get requirements and other templates from my business counterparts, the time to development has been reduced dramatically. My initial projections are that we have an 80% improvement in that process. Any company's engineering and software teams of specialists are highly prized and valuable, so they no longer have to do the boring, tedious content creation of translating Word templates into XSLT. Docmosis has really freed up our capacity to do some real work.

I've shared with Docmosis a list of improvements they could make, and they've been very customer-centric and responsive. They don't always deliver what we ask, but they're very conscientious about responding to us. We have some pretty onerous requirements, but they timely respond.

Because we're not using the cloud version, using the Java library version instead, we'd like more visibility and control of load balancing for owned and private cloud.

Another thing I'd like to see is the ability to more dynamically add converters on the fly. They help generate the PDFs.

Also, this was something they suggested and we wholeheartedly agree: a more simplified install process or consolidated JAR. The reason for that is because otherwise you're installing all these other dependencies related to either OpenOffice or LibreOffice, so that that could simplify the ramp-up to deployment.

The barcoding functionality also needs improvement, specifically a more robust handling of it. Right now, they allow for 1D barcodes, so eventual integration of 2D barcodes would be well-received.

I'd also like some sort of native support for e-signatures.

Fonts, I think, are a little tricky, and so the workaround, on the client-side, is just to address it at a system level, make sure your core system has the fonts necessary for your documents. That's completely okay, but for teams that are operating a couple of layers up in the stack, if they don't have access to that system level, installing fonts and so on just becomes a little more difficult and requires more coordination. That'd be an opportunity to make it simpler or the developer, because the developer isn't always the system manager.

I use a feature within Docmosis to embed templates within templates, and there are some technical limitations, and I don't think it's Docmosis' doing, but there are some limitations in operating with headers and footer when you're using that feature. I get the rationale for not being able to make enhancements around that, but I would want enhancements around that nevertheless.

We engaged with them as far back as the fall of 2014, and we began implementation around that time. But the project, internally as a company, was on and off, due to our systems team's capacity to handle the project. For all of 2015, we had it semi-implemented, but didn't actually have it in a live environment until January of this year. It depends on where you mark the start, but from when we went live with it in a production capacity would be from January 2016. But we've been getting support from them, we've been a paying customer, since last year.

We've had no issues with deployment.

We did some load testing of our daily thousands and thousands of documents, specifically of our spammer, to make sure we could handle the volume. There were no problems at all with the stability of Docmosis.

If we ever ran into a bottleneck, we could always initiate more Docmosis core servers with additional converters. There have been no scaling issues there.

Support@docmosis.com has generally been very responsive, usually within a day of an email. They're willing to jump on a call, too, to walk us through more complex scenarios. I appreciate their courage as they try to understand what we're trying to accomplish, why we're doing it, and try to think outside the immediate problem to see if the direction we're going in makes sense. They take a very consultative approach.

I don't remember the name of the solution, but it required XSLT formats as templates and then to merge data, which was very powerful and performant, but it didn't have load capabilities, converters, and it required translation from Word to XSLT, which was consuming our dev resources. We wanted to free up our developers from that kind of task to focus more on valuable activities.

Docmosis will free up developers, but then the burden falls on someone else, so more attention needs to be spent on Word templates themselves. They need to be as true to the desired form as possible to get a good end result. Someone must take charge of managing and creating Word or OpenOffice templates.

Also, there are a few deployment flavors -- cloud, web service for on-premise, and Java libraries. So picking the right mix is key.

It does a beautiful job of taking Word docs and turning them into PDFs with merged fields. That's really what we use it for.

This is the cornerstone of our office's functionality, where people can create templates, create an offer template, and then a recruiter can just go into a couple of fields and they have a beautiful offer letter. It's really not just for our organization; it's a core functionality in our product.

Right now, the product can be a little finicky with background images, sort of how the tabs work when you try to underline something. Sometimes that won't get reproduced, but those are pretty minuscule cases.

I think the biggest thing that we would love in the future is if it had a little more logic built into it, so you if the following field is present, then show this block of text, and have that be in really simple, not developer-level coding, but like something that a non-technical person could easily do.

We've been using if tor almost exactly a year.

Deployent was really easy. We had it integrated, I think, within a week or so.

It's just gone really well so far. We've had no issues with instability.

We've been able to scale it to our needs.

I think that's been one of the really standout things: the support has been a 10. They've been unbelievable. We needed a font that wasn’t a part of the package and they added it in two hours. It was unbelievable, they have been awesome.

We didn’t have anything before this.

I didn't actually perform the hands-on initial setup. The team doing it said it was easy and not a problem at all. I can only assume that they were in good shape with the setup.

We implemented it in-house. We have a reasonably complex setup just because it had to integrate with multiple, different APIs in our product. We thought it was going to take longer than it did.

We evaluated a couple different options, but we liked how clear they were about the functionality. They seemed to be like a small company; they'll be responsive to our needs. I think the price is right and mostly our engineers liked it. That was the main thing that won us over.

Go for it. It's been really smooth for us.