How a Sustainability Certification Nonprofit Automated Certificate Generation in Dynamics 365

Summary

This post started with a real request. A Netherlands-based sustainability certification company that runs its certification programme on Dynamics 365 wanted the certificates it issues to come straight out of the CRM, instead of being rebuilt by hand in a document every time.

The problem itself is common. Certification bodies, testing labs and manufacturers issue certificates every day, and in most organisations that still means a Word template, a lot of copy and paste, and a PDF sent by email. The data that belongs on the certificate already lives in Dynamics 365, so why can’t the certificate come straight from the record? In this blog we build exactly that. A Generate Certificate button on a Dataverse form calls a Custom API, a small plugin hands the data to an Azure Function, and a branded, print-ready PDF comes back in about four seconds. Today the PDF is stored on the record as a base64 string, previewed and downloaded right on the form. Because the renderer only returns bytes, sending the same file to SharePoint, Azure Blob Storage or an email is a change to one step, not a rebuild.

In This Blog

This blog walks through a complete, working certificate generator for Dynamics 365, from the data model to the button, using a product certification scenario.

• The Scenario: A certification body issues product certificates and needs every one to be accurate, branded and traceable.
• The Approach: Keep the data in Dataverse, render the PDF in an Azure Function, and connect them with a Custom API.
• The Action: One click on the form produces the certificate, stores it on the record and shows a live preview.
• The Outcome: No manual formatting, no retyping, no per-document licence fees, and a design that can later publish to SharePoint or Blob storage.

Table of Contents

Business Challenges

A certificate is a legal statement: this product, made by this company, meets this standard, from this date to that date. When it is produced by hand, the risks are small individually and expensive together.

• Copy and paste errors. Product names, model numbers and expiry dates are retyped from the CRM into a document. One wrong digit on an issued certificate means a reissue and an awkward conversation.
• Template drift. Every coordinator keeps a slightly different copy of the Word template, so logos, wording and signatories quietly diverge.
• No trail. Once the PDF leaves someone’s desktop there is no record of which version was produced, when, or from which data.
• Platform limits. Dataverse plugins run in a sandbox that cannot lay out and paginate a PDF, and a JavaScript-only solution would expose service keys to every user’s browser.

Solution Overview

The demo uses a fictional certification body, Contoso Product Assurance, which certifies products made by manufacturer accounts against its own published standards. The whole flow runs from a single button:

1. FormGenerate CertificateCommand bar button on the Product Certificate form
2. DataverseCustom APIBound action cf_GenerateCertificate
3. PluginCollect the dataCertificate, product, holder and standard
4. AzureRender the PDFFunction returns the file as base64
5. RecordStore and previewBase64 saved, previewed and downloadable

Architecture

• Data modelThree custom tables (Standard, Product, Certificate) plus the standard Account table for manufacturers.
• Custom API and pluginOne server-side entry point. The function key never reaches the browser.
• Azure FunctionA .NET 10 renderer on the Consumption plan. Vector PDF, embedded fonts, QR code.
• Form experienceGenerate and Download buttons plus an inline PDF preview panel.

Technical Approach

1. The data model

Everything lives in one solution, CFCertificateGeneration, so it moves between environments as a unit.

The certificate number is a Dataverse auto-number column with the format CPA-{DATETIMEUTC:yyyy}-{SEQNUM:5}, so numbering is guaranteed unique by the platform rather than by a person. The certificate holder defaults to the product’s manufacturer and can be overridden when a brand owner holds the certificate for a product someone else makes.

2. The renderer

The PDF is drawn with SkiaSharp and the QR code with QRCoder, both open source. The same drawing code targets either a PDF page or a PNG bitmap, which means the image you check during development is exactly what the customer receives. Text is real, selectable text in embedded fonts, every graphic is a vector shape rather than an image, and long product names shrink to fit instead of overflowing the frame.

public RenderedCertificate RenderPdf(CertificateRequest request)
{
    Validate(request);
    using var output = new MemoryStream();
    using (var document = SKDocument.CreatePdf(output, metadata))
    {
        var canvas = document.BeginPage(842f, 595f);   // A4 landscape, in points
        Draw(canvas, request);                        // same code paints the PNG preview
        document.EndPage();
        document.Close();
    }
    return new RenderedCertificate(output.ToArray(), FileNameFor(request.CertificateNumber));
}

Branding is configuration, not code. The brand name, monogram, title, colours and footer are read from app settings such as Certificate__BrandName and Certificate__PrimaryColor, so a second certification body is a settings change. Draft certificates carry a DRAFT watermark automatically.

3. The Azure Function

A single HTTP function, POST /api/certificates/render, protected by a function key and hosted on the Windows Consumption plan. It takes the certificate values as JSON and returns the file plus the metadata needed to store it.

{
  "fileName": "Certificate-CPA-2026-01000.pdf",
  "contentType": "application/pdf",
  "sizeBytes": 174404,
  "sha256": "<hash of the file>",
  "generatedOnUtc": "2026-09-30T07:12:41Z",
  "pdfBase64": "JVBERi0xLjQK..."
}

The function deliberately does not decide where the file goes. It renders and returns. That single decision is what keeps storage flexible later.

4. The Custom API and plugin

The button does not call Azure directly. It calls a bound Custom API, cf_GenerateCertificate, whose plugin reads the certificate, product, holder and standard, applies the business rules, and calls the function from the server.

• The key stays on the server. The function URL and key live in environment variables that only the plugin reads. Nothing sensitive is shipped to the browser.
• One entry point for everything. The same action can be called from the form, from Power Automate, or from another system through the Web API.
• Business rules in one place. Suspended and Withdrawn certificates are refused with a clear message; Draft certificates are watermarked.

var certificate = service.Retrieve("cf_productcertificate", target.Id, columns);
if (status == StatusSuspended || status == StatusWithdrawn)
    throw new InvalidPluginExecutionException(
        "A suspended or withdrawn certificate cannot be generated. Reinstate it first.");

var request  = BuildRequest(service, certificate, isDraft: status == StatusDraft);
var rendered = Render(Settings.Load(service), request, tracing);   // POST to the function
Store(service, certificate, rendered);                             // today: base64 on the record

5. The button and the preview

The command bar has two buttons: Generate Certificate and Download Certificate, both available once the record is saved. If nothing has been generated yet, Download says so instead of failing. Generate calls the Custom API through the client API; Download hands the base64 straight to the platform’s own file handler.

Xrm.WebApi.online.execute({
  entity: { entityType: "cf_productcertificate", id: recordId },
  getMetadata: () => ({
    boundParameter: "entity", operationType: 0, operationName: "cf_GenerateCertificate",
    parameterTypes: { entity: { typeName: "mscrm.cf_productcertificate", structuralProperty: 5 } }
  })
});

// Download: no Blob plumbing needed, openFile accepts base64 directly
Xrm.Navigation.openFile({ fileContent: record.cf_pdfbase64, fileName: record.cf_pdffilename,
  mimeType: "application/pdf", fileSize: record.cf_pdfsizebytes }, { openMode: 2 });

An HTML web resource beside the fields turns the same base64 into an inline PDF preview, with the file name, size, generation time and version, so users check the certificate without leaving the form.

6. Where the PDF goes next

Storing base64 on the record is the simplest thing that works, and it is honest about its limits. Because only the Store step knows about storage, each of these is an isolated change:

Impact

These figures are measured on the working build described above, running against a Dynamics 365 sandbox and the Azure Functions Consumption plan.

• ~4 sFrom button click to PDF stored on the record
• 100%Vector output: no raster images, sharp at any zoom or print size
• $0Licence fees for the generator itself

What it costs

Certificate and document generation is often bought as a third-party add-on, usually licensed per user or per generated document. This build has no such fee. What remains is a small Azure footprint, and at normal certification volumes almost all of it sits inside Azure’s free monthly allowances.

Conclusion

A certificate is only as trustworthy as the process that produces it. By rendering it from the Dataverse record, through a Custom API that owns the rules and an Azure Function that owns the layout, every certificate is consistent, traceable and one click away. The design stays small on purpose: the renderer returns bytes, and where those bytes go is a decision you can change later without touching the layout or the business rules.

The same pattern fits any document that is really a view of CRM data: certificates of conformance, training completion certificates, warranty cards, compliance letters or quotations.

FAQ

Get in Touch

Suchit Chaudhari

Dynamics 365 & Azure, CloudFronts

Builds Dynamics 365 and Power Platform solutions that connect CRM data to Azure services, with a focus on document generation, integrations and practical automation.