Generate meeting and board packs, secure PDF files, archive documents in PDF/A format

Posted at: 14:11 on 28 March 2019 by Muhimbi

When I recently wrote the 10 years of Muhimbi article, it gave me the opportunity to reflect on how we communicate about our products and services. We tend to focus on the hard-core technical facilities such as the ability to Convert, Merge, Watermarks, Secure and OCR files, which resonates well with our technical audience, but this doesn't answer the question of WHY you would need such functionality.

Fortunately, they let us out from time to time, especially when we go to trade shows, which is always enlightening as we get to talk to people, for real, like in face-to-face. It is at times like this that we find out what people really use our software for. Naturally our products and services are also used in the most obscure scenarios that we could never even dream of, but for the vast majority of the customers the same handful of scenarios are mentioned time and again. We have summarised these scenarios below.


Generating meeting and board packs

Although some organisations fully automate this as part of a larger workflow, many customers use our standard user interface for merging files to generate meeting or board packs. The reason for generating these packs is easy to understand. Typical meetings require a Word, Excel and PowerPoint file to be distributed to attendees. As we are no longer living in the 20th century, people want to consume these documents digitally. Up until a couple of years ago this usually meant reading the documents on a Windows based laptop, but times have moved on and people use all kind of devices including tablets, Chromebooks, and even mobile phones.

These devices all have their own strengths, but other than Windows Laptops, they tend to display Office (and other file formats) in a way that is usually a bit - and sometimes a lot - different from the way the original author intended. The only way to guarantee that the documents are displayed in exactly the same way as intended, is to convert them to PDF, and distribute everything as a single file.

Traditionally, organisations have used complex, desktop based, PDF editors for this purpose, the likes of Adobe Acrobat. This software is not particularly easy - or quick - to use and tends to end up being quite expensive if it needs to be rolled out to more than a handful of people in an organisation. It doesn't help that these meeting documents are often changed just before the meeting starts, resulting in a last-minute rush, causing all kinds of nasty errors.

Although never intended to be used specifically for this kind of scenario, Muhimbi's range of PDF Conversion products, and particularly the SharePoint versions, provides an excellent solution to create meeting packs. It requires no training, does an excellent job when converting and merging files into a single PDF, and can do so in either an automated fashion - via workflows - or simply via the SharePoint user interface. The results look perfect, on any device.


Watermarking and securing files downloaded from SharePoint

Another common scenario we hear about is watermarking, and securing, PDF files in real-time the moment they are downloaded. It doesn't really surprise me that this is popular, as we built this facility based on real-world customers asking for this exact functionality.

It is used for all kind of reasons and scenarios, but we see it most commonly used as a DRM light solution. What we mean with this is that a full-blown DRM solution (a.k.a IRM / RMS / AIP) tends to be difficult to implement and roll-out, and - no matter how powerful - has all kind of nasty side effects. What organisations need is something that is good enough, and in our case good enough means embedding the user's name, IP address and timestamp in a PDF the moment the file is downloaded from SharePoint.

Some organisations visibly display this information in the downloaded PDFs as a deterrent to prevent 'sharing' of sensitive or valuable documents. Others embed the same information in an invisible manner leaving it as a surprise - for people who 'misplaced' a document - for the yearly performance review.

If this is a topic that is of interest, have a look at the SharePoint on-premise (SP2007-2019), and the SharePoint Online examples. Drop us a line if you have any questions.


Sharing files in PDF format

We provide a lot of functionality out-of-the-box; workflows, watermarking, merging, security, OCR, but quite often people just need to take a source document, being it in Word, Excel, PowerPoint, MSG, AutoCAD, Image, or HTML format, and turn it into a PDF as that is just so much easier to share via email, websites or other medium.

Our customers especially appreciate the ability to easily turn almost any document into a PDF when it comes to Freedom Of Information requests. You cannot just distribute emails in their original MSG format, or share InfoPath forms as a combination of XML and XSN files. Not only is PDF the perfect file format for these kinds of requests, it also strips out personal information and other metadata.

Fortunately our software supports most file formats used in office environments.


Archiving files

In the Enterprise Document and Content management market we operate in, each document typically goes through a life cycle. A document is created by a person or group of people, the document is then reviewed by a manager and ultimately - if you are lucky - approved.

While a document moves through these various stages, in the background an automated workflow process organises the entire process. Emails and other notifications are sent out when certain stages are reached, people are asked to take action, reminders are sent out etc.

One of the final steps in the process is usually to take the document, regardless of the source file format, convert it to PDF, add a watermark to include status as well as other metadata associated with the document (who approved it, value, category, priority etc), and write the PDF to a records centre or other archive.

Our range of PDF Conversion products come with a set of building blocks that workflow designers can insert in whatever part of their business process they want to. We don't force a certain methodology or process upon you, just use our facilities as you see fit.

When we sit down and write the specification for whatever amazing new feature we are planning next, we always envisage these massive and complex enterprise level workflows that our software participates in. However, more often than not, the workflow only contains 2 steps

    Step 1: Has the document been approved?

    Step 2: Convert it to PDF.

    Step 3: There is no step 3.

Keep in mind that various regulatory bodies specify standards for archiving files. More often than not the exact PDF version to use is PDF/A. Our software supports this sub-standard, one less thing to worry about.


Converting InfoPath forms

As the only serious player in the InfoPath to PDF conversion market, it doesn't surprise us that many organisations use our software to convert InfoPath forms to PDF.

InfoPath is a particularly tricky format that makes it nearly impossible to share forms with someone outside the organisation, and often even inside the organisation. In the right hands InfoPath is an excellent solution, but in many cases.... oh well, let's not dwell on that.

As so many organisations come to us to convert InfoPath forms to PDF, over the years we have added all the bells and whistles you can imagine. We even make it possible to convert files that are attached to InfoPath forms, and provide full control over which views to convert as well as which views NOT to convert.

Have a look at the whitepaper we authored on this topic, Making InfoPath Documents Available for Long Term Archiving.

Similar to the Archiving topic discussed above, InfoPath to PDF conversions are usually coupled with very simple workflows. Once a form reaches a certain status, e.g. approved, automatically convert it to PDF, apply a watermark as well as PDF security, then write it to an archive.


Build random stuff using workflows

As mentioned previously, most workflows that our components participate in are very basic and contain only a handful of steps. However, as the topic of automating processes using workflows is so important to our customers, we have really gone the extra mile and added support for most of the popular workflow platforms.

As a result we support SharePoint Designer workflows, Workflow Manager Workflows, Nintex Workflow (2007-2019), Visual Studio, K2, Microsoft Flow, Azure Logic Apps and anything that knows how to consume a REST endpoint.

Why use workflows? Well there are as many reasons as there are organisations, but the key reason I always mention is the ability to automate processes and take the human error factor out of the equation. Even for the most basic workflows, including the simple 2 steps flows mentioned previously, you cannot trust humans to always get it 100% right, not even for the most disciplined teams.

Time and again we see situations where, for that last-minute change, a crucial step was forgotten, or the wrong output folder was picked. ONLY by automating business processes using workflows can you guarantee that the same steps are always carried out without fail.

Any questions on these topics, or anything else? Contact us, we love to help.


Labels: , ,

Converting and Archiving InfoPath Forms to PDF using Microsoft-Flow

Posted at: 18:16 on 22 March 2019 by David Radford

This article is based on a post Clavin Fernandes made to his personal blog, the information in it is used with his permission. Thank you Clavin!

Ever since Microsoft announced the retirement of InfoPath, people responsible for archiving forms and maintaining their accessibility have been busy searching for alternatives to InfoPath.

Luckily, we’ve been busy with this as well!  So, we started with a previous post and decided to update it here using some of the new functionality available with Microsoft Flow.


Using Flow to convert and archive InfoPath forms is a bit more involved than doing the same in SharePoint, as InfoPath uses two files to create a single form, an XML (data) file and an XSN (template) file. In this post we will create a simple Flow that is triggered whenever a form is added to a folder in a SharePoint Online Library. Once added, the form is automatically converted to a PDF stored in a OneDrive for Business folder.

This is just an example, it can easily be adjusted to use different file services (e.g. the trigger can be for files uploaded to OneDrive,, DropBox, Google Drive or can even be used to Migrate your SharePoint On-Premise InfoPath Forms to SharePoint Online etc).


Before we begin:


Create the Flow

From a high-level perspective, the Flow looks as follows: 

Note: Converting an InfoPath form is similar to converting any other document type using Muhimbi's Flow Actions, but - as it is needed during conversion - you need to pass in the XSN file (the file content, not the URL to the file) alongside the XML file.

The Flow consists of the following elements:

  • Trigger - When a file is created in a folder: Specify the path to the SharePoint Online folder to monitor for new files. (To trigger a Flow for files created anywhere in a Library, use the ‘When a file is created (properties only)’ trigger, and retrieve its content using Get file content.)
  • Get file content: Specify the path to the SharePoint Online location where the XSN has been published to. (By default it is stored in the Forms Folder, e.g. “
  • Convert document: Insert the Muhimbi PDF Convert Document action, and fill it out as follows. (see the screenshot below for details):

    • Source file name: File name” the output from the “When a file is created in a folder” trigger.
    Source file content: “File Content” the output of the “When a file is created in a folder” trigger.
    Output format: PDF
    Template file: “File Content” the output of the “Get file content” action, which contains the InfoPath XSN file.
       Do not just pass the path to the XSN file into the Muhimbi Action as it doesn’t have the privileges to read that file.
  • Create file: Specify the path to the OneDrive folder where the converted PDF files are written to. Pass in the 'Base file name' field returned by the Convert Document action, making sure that it is suffixed with '.pdf'. In the 'File content' field pass in the 'Processed file content' returned by the Convert document action.

    Voila- You’re finished!  Now, publish the Flow and then save an InfoPath form in the SharePoint Online folder to test the Flow. After a few moments a PDF file will appear in the OneDrive destination folder.

    This is just a basic example. Please keep in mind that the Muhimbi PDF Converter also comes with facilities to convert files attached to InfoPath forms as well as choosing which InfoPath view or views to convert.

    For more Microsoft Flow, Logic Apps & PowerApps Tutorials and Blog posts, see our Knowledge Base.


    As always, if you encounter any difficulties, please feel free to contact our friendly Support Desk for any assistance you may require.

      Labels: , , , ,

      Subscribe to News feed