Implementation Methodology

This page describes how to deliver Docentric AX on a D365FO project, end to end. It is organized into five stages:

1. Set up the environment and tooling
2. Analyze and decide – scope, approach, template strategy, and storage
3. Build and prove the first report, then repeat the pattern
4. Distribution – print destinations and Print management
5. Test, release, and hand over

The stages are a sequence, but not too rigid. In particular, Build (Stage 3) and Distribution (Stage 4) run together in practice – you configure distribution for each report as you build it. Some activities (scope, distribution requirements, Print management) are part of any D365FO implementation; where that is the case, this guide focuses on what Docentric adds or changes rather than repeating standard project practice.

The guiding principle throughout: implement one representative report end to end, document the pattern, then apply the same pattern across the rest of the document scope.

Stage 1: Set up the environment and tooling

1.1 Prepare the D365FO environment

Install the Docentric AX Framework in the appropriate D365FO development or sandbox environment. (Prerequisites, model list, and version support are in Before You Start.)

• Install the models. Start with the core four: Docentric AX, Docentric AX Extension, Docentric AX Emails, and Docentric AX SSRS Replicas. Install them via scripts or manually.
• Apply the license. Unlock the product with the appropriate license. Note for partners: do not use your partner license in client environments.
• Load the system templates. They ship as AOT resources with the Docentric AX SSRS Replicas model. In the Docentric AX Workspace, click the Reports tile and confirm the prompt to load them. This adds around 80 entries to the Docentric AX report setup form, each configuring an SSRS report/format combination with its matching Docentric replica template.
• Verify the out-of-the-box install. Reprint one test report that has not been customized – Purchase order confirmation is a good choice. Use Preview/Print > Original preview - it should automatically use the Docentric replica template. If you cannot see a difference from the standard SSRS output, enable the Discover report technical name option (User options > Account > Docentric settings > Discover report technical name) and re-preview – the info message confirms which template was used (@SSRS_BUILTIN_DESIGN@ or @DOCENTRIC_DEFAULT_TEMPLATE@).
• Configure security roles. Decide who will work on templates, setup, and technical extensions, then assign the relevant Docentric security roles and confirm users can reach the Docentric forms.

How Docentric reaches TEST, UAT and PROD

You install the Docentric models once, in the development environment. From there, they travel to TEST, UAT and PROD inside your regular deployable packages, together with your own code. There is no separate installation step per environment.

This is different per environment:

• License: each environment needs the (same) Docentric license applied after the first deployment. Partners: client environments always use the customer license.
• Setup data: Docentric-specific setup (such as: report setup, email templates, templates stored outside AOT) and relevant D365FO setup (Print management) are data, not code. They move between environments through the Docentric data entities and template deployment tools, covered in Stage 5.2.

Useful references: D365FO installation guide, Docentric AX parameters, Docentric AX reports setup.

1.2 Prepare local machines for template design

Install the Docentric AX Designer (Microsoft Word with the Docentric Add-in) on the machines used for template design. Requirements and the reason the Add-in is mandatory for data-bound content are covered in Enablement, Demo Environment & Training. After installation, confirm Word shows the new Docentric AX or Docentric ribbon tab.

Stage 2: Analyze and decide

This stage produces the decisions that shape everything later on: what is in scope, how each report will be implemented, and how templates will be owned, stored, and versioned.

2.1 Define the document and report scope

Defining scope is a standard part of any D365FO project, but do it early and for each business document capture the following:

What to capture	Example
Business document name	Sales order confirmation
Business process	Post & print Sales order confirmation
Report name and technical SSRS report name (if they exist)	Sales order confirmation, SalesConfirm.Report or: New report <report_name> will be developed, because <reason>
Path to reprint the report (useful for testing)	Form: Sales order confirmations Path: Sales and marketing > Sales orders > Order confirmation
Legal entity scope	USMF, DEMF
Language requirements	en-us; es; de
Branding requirements	All documents have the same branding. It will be developed for the first report and applied to other reports.
Output format	PDF for emailing, PDF/A for archiving
Distribution requirements	Email and SharePoint Note: add as much details in this phase. Capture them already in this phase, even though you will configure them later in Stage 4. Discovering them late is a common cause of rework.
Print management requirements	Original and Copy Print management settings: Original configured for Docentric Email print destination; Copy configured for Docentric File print destination > Save to SharePoint, save with SharePoint metadata.
Additional data source requirements	Additional SO Header fields: <list of field names with specification how to populate each field> Additional SO Line fields: <list of field names with specification how to populate each field>
Additional format requirements	Approach 1 (optimal if you already know Docentric): add new dummy content to already existing Docentric template, mark clearly (with yellow highlighter, or red text color) that it should be replaced, write the field name that should be bound here. Approach 2: print the report as .docx, add new dummy content to it, and clearly mark which fields will come there. Approach 3: screenshot of the printed PDF, use one of the free or paid screenshot tools to mark where in the layout to add the new fields. Approach 4: printed PDF, use one of the available free or paid tools for PDF editing to mark where in the layout to add the new fields.
Ownership of the data source and template design before and after go-live (this drives the Implementation approach decision in 2.2)	Before go-live: partner owns data source and template design; customer is being onboarded for template design. After go-live: partner owns data source; customer owns template design.

A common starter set (the exact set depends on the customer's processes, country, localization, and scope):

• Invoices: Sales invoice, Free text invoice, Project invoice
• Purchase order confirmation
• Sales order confirmation
• Packing slip
• Customer account statement
• Vendor payment advice
• Check
• Collection letter

2.2 Choose the implementation approach for each report

For each document, decide three things: the data source type, how you will maintain the data source, and the format starting point.

Answer these questions first:

• Do you anticipate data source modifications? Are they simple (for example, adding existing table fields) or complex (adding lists of transactions, complex calculations, external integrations)?
• Who will implement and maintain the data source: project team, support team, or customer, and do they have the right skills (developers, ER specialists)?
• Do you anticipate format modifications? Does a Docentric replica exist for this report, and is it close to the required result?

Then work through the decisions:

DECISION 1: Data source type

Decide between an SSRS-based and ER-based data source.

SSRS-based data source gives you full X++ flexibility for complex data requirements. Choose it if:

• Developers are available, while ER specialists have little or no experience.
• Complex data source needs are identified.
• SSRS-based customizations have already been done before introducing Docentric.

ER-based data source enables the configuration-based approach, without coding and without deployment. Choose it if:

• Simple to moderate data source needs are identified.
• Experienced ER specialists are available.

If you choose ER-based data sources for any report, also install the Docentric AX CBD Replicas model (it can be added at any point).

DECISION 2: How to maintain the data source

Decide between the Docentric pattern, SSRS pattern and ER configurations.

Docentric pattern is based on implementing or extending Docentric DSP classes. It is usually the optimal choice, preferred by developers. Choose it if:

• You use the SSRS-based data source. This is a default choice for most developers.

SSRS pattern is a standard D365FO pattern for modifying the SSRS data source, by extending the RDP tables and DP classes (or, less frequently, queries). You might want to choose this option if:

• The report has already been customized before you introduced Docentric. Therefore, you have already extended multiple SSRS-related artefacts, and it makes sense to keep maintaining them. Alternatively, if you haven’t made too many changes so far, you might want to consider moving the implementation to a DSP class and continue to use the Docentric pattern.
• You have just started your first Docentric project and are still not familiar with the Docentric pattern, but you are under time pressure to deliver the report. In that case, it is perfectly OK to pick the SSRS pattern. Once your developers feel the simplicity of the Docentric pattern, they will never want to go back to the SSRS pattern 😊.

ER configurations are the only possible choice if you decide to use the ER-based data source, based on the expected complexity of the requirements and experience  of your ER specialists.

DECISION 3: What is the format starting point

Decide between the Docentric replica template, Docentric template from scratch and ER format.

Docentric replica template as a starting point guarantees the fastest results. It can be combined with all three data source maintenance techniques selected in the previous step. Choose it whenever:

• Docentric replica template is available for your report, and
• The replica is close enough to the expected result, so no serious rearranging of the layout is required.

Docentric template from scratch is an alternative to the first option if you want to use Docentric templates. Just as when starting from the existing replica design, you can combine it with all data source maintenance approaches. Choose it if:

• A Docentric replica template for the report isn’t available, or
• The replica design is too different from the target layout.

ER format completes the standard ER pipeline. It can be combined only with a pure ER-based data source that is maintained through ER configurations. Choose it if:

• Minimal design changes are anticipated, and
• ER specialists are available.

One possible outcome:

Report	Data source type	Data source maintenance	Format starting point
Sales order confirmation	SSRS	SSRS RDP + DP extension (previously already done)	Docentric SSRS replica template
Sales invoice	SSRS	Docentric DSP extension	Docentric SSRS replica template
Collection letter	ER	ER configurations (minimal changes expected)	Docentric CBD replica template
Purchase order confirmation	SSRS	Docentric DSP extension	Docentric template from scratch

2.3 Define the template strategy

Before creating many templates, agree on:

• who owns templates during implementation, and after go-live,
• where templates are stored (see 2.4 Choose the template storage below),
• how templates are named,
• how versions are controlled,
• how templates move from DEV to TEST/UAT to PROD,
• who maintains them: consultants, developers, or trained customer users.

2.4 Choose the template storage

Choose storage based on governance, ownership, deployment, security, and post-go-live maintenance:

• AOT resources: best choice when templates should be source-controlled and deployed with code. Suits partner-owned baseline templates, regulated documents, or anything that should follow the code release process.
  Note: Docentric SSRS and CBD replica templates (also called: Docentric system templates) are delivered as AOT resources.
• Azure Blob storage: good choice when templates should be stored centrally and maintained outside the deployable-package process. Suits project- and customer-owned templates that may change after go-live. Simplest choice without any additional setup.
• SharePoint: excellent choice when business or key users need easier access and the organization already uses SharePoint for document governance. Suits project- and customer-owned templates that may change after go-live.
• File system: available for on-premises environments only.

2.5 Estimate the effort per report

How long does one report take? It depends mostly on (1) the three decisions above, and (2) customization scope, so estimate per report, after the decision table is filled in.

When estimating, have this in mind:

• The first report might last multiple times longer, because it includes the learning curve for your team. It is also why the methodology starts with one representative report: you pay the learning cost once, on a report where it is cheap.
• Sales invoice often takes the longest in almost every project, due to legal requirements, localization, and the number of variations. Estimate it separately, and never use it to calibrate the rest of the scope.

Here are few examples of effort estimation for a team that has completed the enablement path:

• Replica template, layout changes only (branding, colors, minor rearranging): 1 - 4 hours
• Replica template + simple to moderate data source extension through a DSP class: 1 - 4 hours for data source, 1 - 4 hours for template
• Template from scratch (average complexity), standard data source: 4 - 16 hours

The ranges cover build and unit testing. They exclude requirements gathering, UAT cycles, and rework caused by late requirement changes, which is why capturing distribution requirements in 2.1 matters.

Stage 3: Build and prove the first report

3.1 Implement the first end-to-end report

The first report should prove the complete pattern:

• Register the report in the Docentric report setup (if it is not already registered as a result of installing the SSRS Replicas model).
• Generate the DDSP file.
• In the Docentric template designer Create a template from scratch or modify the existing replica template.
• Assign the template to the report and store it on the agreed storage type.
• Configure the print destination.
• Test the distribution channels: preview, print, email, download, and archive.
• Test interactive and batch execution, with and without Print management destinations.
• Document the decisions made.

Reuse the same pattern for the next reports.

3.2 Design templates in the Docentric AX Designer

Recommended practices:

• Start from a replica when one is available.
• Keep the layout simple and readable, and use Word styles consistently.
• Use standard Word features and Word tables for clean layout.
• Separate header, body, totals, and footer areas clearly.
• Test with realistic data, and test edge cases: long addresses, high values, many lines, discounts, multiple tax rates, and multiple pages.
• Test language and legal entity variations.

The goal is not only correct output at go-live, but a template that is easy to maintain later.

3.3 Add data through a DSP class when needed

When the required data is not in the standard report data source, or additional document processing or distribution is required, extend a Docentric DSP class. Typical cases: adding fields or records (for example: delivery, payment, tax, bank, legal-entity-specific, calculated data, etc.), custom placeholders, additional report attachments not supported through the UI, or special delivery and integration requirements.

Recommended practice:

• Implement the logic to add the required data, placeholders, attachments, or integrations.
• Regenerate and reload the DDSP file after data source changes.
• Add the new fields to the templates.
• Retest all templates that depend on the changed data source, and the scenarios that required the new placeholders, attachments, or integrations.

This is a technical task with the Docentric Technical training as a precondition. Study the patterns in the existing replica DSP classes, and search the blog and forum for DSP method examples.

Stage 4: Print destinations and distribution

Defining how documents are distributed is a standard part of any D365FO project, but Docentric significantly extends what is possible, so it is worth matching requirements to Docentric capabilities early. Capture these requirements during Stage 2 - Analyze and decide and configure them here, alongside building each report.

4.1 Define print destination and distribution rules

For each document, clarify:

• Should it be printed, emailed, downloaded, archived, and/or saved to SharePoint, Azure Blob storage, or another destination?
• Should email message parts (subject, body, output filename) be static or dynamic? If dynamic, which placeholders and business data should be available?
• Should files be attached? Should they be loaded from document attachments, or generated dynamically?
• Should the output be signed, encrypted, zipped, or PDF/A conformant? Saved with metadata?
• Are different settings needed for original, copy, internal, external, or batch scenarios?

When a document is emailed, also clarify: who receives it (Customer/Vendor contacts, purpose, custom logic, or manual selection); whether Cc/Bcc are needed; whether the sender is fixed, the current user, legal-entity-specific, or a system account; whether body and subject depend on language or legal entity; and how failures are handled.

Map these requirements to Docentric print destinations, Print management setup, email templates, placeholders, email tokens, archive settings, and any custom data extensions. See the Print destinations how-to manuals and the Advanced functional training videos.

4.2 Manage Print management setup carefully

Print management can become complex; Docentric provides tools that simplify its review, maintenance, export, and migration.

Recommended practices:

• Keep settings as simple as possible and avoid unnecessary overrides.
• Prefer conditional Print management settings over multiple overrides where possible.
• Document why each override and each conditional setting exists, and use consistent naming.
• Test Original and Copy scenarios, all conditional settings, batch and non-batch execution, and all legal entities in scope.
• Use the Docentric Print Management Utilities form for tabular review and manipulation.
• Use the Docentric Print Management Settings Package data entity to move settings between environments and to export them for review.

Stage 5: Test, release, hand over and maintain

5.1 Test business scenarios

For each implemented document, test:

• preview from the business process,
• print destination execution,
• email recipient resolution, subject, body, output filename, and attachments,
• archiving and file saving to required storage,
• PDF generation,
• batch execution,
• Print management original, copy, conditional, and override behavior,
• different legal entities, languages, customer/vendor groups, and currencies,
• long addresses and item descriptions,
• zero, negative, and large amounts,
• multi-page output,
• security and user access,
• migration from UAT to PROD.

5.2 Versioning, lifecycle, and moving between environments

Define how templates are versioned and promoted. A recommended lifecycle:

• Draft in DEV or sandbox.
• Review with the functional consultant.
• Test with realistic data.
• Review with the business owner.
• Promote to UAT.
• Freeze before go-live.
• Move to PROD through the agreed deployment process.
• Keep a backup of the approved go-live version.
• Apply later changes through change requests.

Avoid ad hoc changes directly in production unless the customer has explicitly accepted that governance model.

When moving Docentric setup between environments:

• Keep Docentric models aligned between source and target.
• Templates, report setup, Print management settings, and storage references may all need migration.
• AOT-stored templates follow the deployable-package/source-control process. Azure Blob storage and SharePoint templates require storage access and governance.
• Export/import Print management settings with the Docentric data entities, and always test imported settings in UAT before production.
• Keep a backup/export of approved production settings before major changes.

5.3 Hand over and train

Before go-live, prepare a short handover package:

• list of implemented reports,
• report setup overview,
• template storage locations and ownership,
• versioning rules,
• Print management related explanation and rules,
• known limitations,
• troubleshooting steps,
• support contact points,
• instructions for changing a template safely.

The training tracks, what each group should be able to do, and the self-serve resources are detailed in Enablement, Demo Environment and Training. The same tracks apply to customer teams.

5.4 Maintain the solution after go-live

Two things will keep changing during a solution lifetime: Microsoft's D365FO version and the Docentric AX version.

Both cases call for the same smoke test. Pick a representative set of documents and retest it after every update:

• one Print management report,
• one emailed report,
• one printed report,
• all reports using Docentric File print destination, such as: saving to SharePoint, saving to Azure Blob storage,
• all reports using any kind of custom integration with external systems,
• all reports where DSP class was customized, or custom business logic and/or integration was implemented by using Docentric API.

D365FO version service updates

The latest published Docentric AX version supports all D365FO versions that Microsoft supports, and new D365FO GA versions are supported from the day of their release.

Three ways to handle the version compatibility, from safest to most work on your side:

1. Upgrade Docentric together with the D365FO update: this is what we recommend, it requires no analysis, and you get the fixes and features from the versions you skipped.
2. Ask us first: while you're planning the D365FO update, write to support@docentric.com with your current Docentric version and the D365FO version you're moving to, and we'll confirm whether they're compatible.
3. Follow the release notes: read the change log periodically, from your installed version onwards, and pay attention to the hotfixes issued due to the breaking changes on the Microsoft side. Optionally, to get notified instead of checking, subscribe to this forum thread. It's where we announce hotfixes first, and it has the instructions for subscribing.

Whichever you choose, include the smoke test in your regular update regression testing.

Docentric AX upgrades

New Docentric versions bring new features and fixes. Upgrading is a normal code change: upgrade the models in the development environment, commit to source control, and promote through TEST and UAT to PROD like any other release.

Who does what

Agree during hand-over who monitors Docentric releases and decides when to upgrade: the partner as part of a support agreement, or the customer's technical team. Leaving this undecided is how solutions end up several years behind, which turns a routine upgrade into a project.

Template changes after go-live follow the change-request process agreed in 5.2.

Summary

A successful Docentric AX implementation is more than designing templates. It needs a clear approach to report scope, data sources, template storage, Print management, distribution, environment migration, testing, and ownership after go-live.

The reliable way to start is to implement one representative report end to end, document the pattern, and then apply that pattern across the customer's document scope.

See also

Implementation Guide (main page) >>
Before You Start >>
Enablement, Demo Environment and Training >>