Why do developers get insomnia? Because of the RESTless APIs…

There are plenty of options when it comes to choosing how to integrate with D365 F&O. But rather like a extensive menu at a restaurant, too much choice can make it difficult to find the right solution for the task at hand!

The purpose of this post is to present an overview of the options available and help direct your decision-making process or, even if you’re not at the level yet to make these sorts of decisions, hopefully it helps you to begin to understand the art of the possible.

At-a-glance comparison

Our initial comparison chart shows our primary integration patterns and helps to highlight what each one is suitable for:

Comparison table of integration patterns for D365 F&O

Key:

  • Real-time: Indicates whether the integration pattern supports real-time data exchange. 
  • Batch: Indicates whether the integration pattern supports batch data exchange. 
  • Complex ETL: Indicates whether the integration pattern supports complex data transformations. 
  • High Volume: Indicates whether the integration pattern is suitable for high volume data exchange. 

A bit more detail

An uninformed eye could be tempted by the Custom service line in the first table, with its four gleaming ticks standing out from the competition!

Let’s go back to basics and describe each method in a bit more detail:

  • Power Platform Integration: Using Microsoft Power Platform allows the creation of custom apps and workflows, that can connect data across the Microsoft eco-system and beyond, using either one of 1,000+ standard connectors, or a custom build.
  • OData: The Open Data Protocol (OData) serves as a standardised way to expose and consume data via RESTful APIs. It allows developers to query, filter, and manipulate data using familiar HTTP methods, to facilitate data exchange with external applications and services.
  • Batch Data API: This API groups records into batches, instead of handling individual records one by one, thus improving performance and reducing overhead, and efficiently transferring bulk data without overwhelming resources. It also allows asynchronous processing, making it suitable for scenarios like scheduled data imports or exports.
  • Data Management Package: Data management packages encapsulate common import and export tasks, ensuring consistency and adherence to business rules, whether migrating data, updating records, or integrating with other applications. They provide a structured approach, promoting data governance and reducing the risk of errors.
  • Custom Service: Sometimes, none of the out-of-the-box solutions cut it and custom API services need to be developed, offering complete flexibility that align align precisely with requirements. Inevitably, this comes at a much higher cost of design, implementation, and maintenance.
  • Excel Integration: Excel remains a ubiquitous tool for data manipulation and reporting (as any CIO battling shadow IT is well aware!). However, D365 F&O allows seamless integration with Excel spreadsheets, allowing users to import/export data, perform calculations, and create insightful reports – all within the more familiar Excel environment.
  • Consumption of External Web Services: D365 F&O can extend its reach by consuming external web services, tapping into third-party APIs such as real-time currency exchange rates, address validation, or payment gateways.

The final showdown

With our new perspective, let’s take a deeper look at the for and against of each method, so here is a more detailed comparison:

Integration MethodProsCons
Power Platform Integration Seamless integration with Microsoft’s Power Platform which includes Power Apps, Power Automate, and Power BI.
Enables rapid development and deployment of apps, flows, and reports without the need for extensive coding. 		Limited to the functionalities and connectors available within the Power Platform.
May require additional licensing. Not suitable for large volumes of data.
OData (Open Data Protocol) Enables real-time integrations, suitable for scenarios requiring immediate data reflection.
Supports standard CRUD (Create, Read, Update, Delete) operations, making it straightforward for basic data operations. 		Not ideal for handling large data volumes.
Discouraged for use with Power BI reports in favour of using the Entity Store. 
Batch Data API Suitable for handling large data volumes by processing data in batches.
Asynchronous processing allows for scheduling and managing data transfers efficiently. 		Not suited for real-time data integration requirements.
May require additional setup and configuration for batch jobs. 
Data Management Package REST API Enables on-premise deployments, providing a solution for environments not fully migrated to the cloud.
Supports batch processing of data, aiding in managing large data transfers. 		Limited to the functionalities provided by the Data Management framework.
May require additional setup and expertise to utilize effectively. 
Custom Service Offers a high degree of customisation and control over the integration process.
Can be tailored to meet complex or unique business requirements. 		Requires development expertise and may lengthen the integration timeline.
Maintenance and support may be more demanding as compared to standard integration methods. 
Excel Integration Familiar interface for users, enabling data import/export using Excel.
Supports data validation and basic data transformation within Excel before importing into D365 FO. 		May not be suitable for complex data integration scenarios.
Dependent on Excel’s capabilities and may require additional setup for automated integrations. 
Consumption of External Web Services Allows for integration with a wide range of external services and APIs.
Provides flexibility in connecting with various third-party platforms. 		May require custom development and additional security considerations.
The ease of integration may vary depending on the external service’s compatibility and API design. 

Conclusion

There’s a good reason for so many integration methods in D365 F&O. Some integrations require speed, or ease of user adaption. Others need to move large volumes of data, or perhaps need to reflect in (near) real time.

When architecting your solution, be sure to give due consideration to what you’re trying to achieve – and definitely don’t try to use one method for all of your interfaces!

What makes Microsoft ERP better than the competition?

It feels like as good time as any to reflect on and celebrate some of the reasons why Microsoft ERP solutions are market leaders – and we’re obviously not forgetting our little cousin D365 BC here. Let’s go!

  • Two tiers of choice, offering entry-level through to enterprise functionality, with competitive pricing along the way. More on the comparison between the two tier choices can be found in the (friendly) battle of the Microsoft ERP solutions.
  • Comprehensive functionality with a wide range of core features across finance, supply chain, and human resources, that also extends across sales, marketing and customer service applications in the wider D365 family.
The range of apps available across the Microsoft Dynamics suite is unparalleled
  • Intuitive design and familiar interfaces that behave like the other Microsoft products that we all use on a daily basis, meaning toolbars, menus and dialog boxes are that little bit less scary.
The sales order interfaces in D365 F&O and D365 BC, taken from a spectacular survey of sales orders
  • Native integration with Entra ID (Azure Active Directory), giving single sign-on (SSO) functionality out of the box, not to mention multi-factor authentication (MFA) and self-service password reset (SSPR) with no extra fuss or hassle.
A user record in D365 F&O, showing the default login provider as Entra ID (https://sts.windows.net)
  • Native integration with Exchange, SharePoint (including Teams), and Dataverse, allowing us to email, share files, and build custom datasets with relative ease.
  • Powerful out-of-the-box APIs and custom integration options from Azure Integration Services, such as Logic Apps, allowing us to bring all line of business applications together.
  • Seamless use with Microsoft Excel and Word, including the ability to tailor output documents in either format, and the truly fantastic D365 Office Add-On:
Most grid views in D365 can be opened in Excel, with the functionality front and centre in General journals
  • Easily formed connections with Teams and Power Platform, not to mention other Dynamics 365 applications, allowing a natural flow of information and process:
An adaptive card in Microsoft Teams, showing a sales quotation approval that connects D365 Sales with D365 F&O
  • Copilot – the powerful and ever-evolving Microsoft AI tool, a product of Microsoft’s $10 billion investment in OpenAI – embedded in all Microsoft applications, including D365 BC and D365 F&O:
The Copilot pane in D365 F&O
  • Native to the Azure cloud, the second largest cloud infrastructure provider with 24% market share in Q4 2023, offering almost unrivalled reliability, security and scalability:
Infographic: Amazon Maintains Cloud Lead as Microsoft Edges Closer | Statista
  • Not to mention, the sheer market strength and staying power of the Microsoft brand:
Track all markets on TradingView

Choosing Microsoft for your ERP solution is a winning formula – why would you go anywhere else?

It’s time for a Party in the Global address book

I was talking to a client yesterday who wondered if there was a quicker way of creating a new Supplier based on an existing Customer record, for the purpose of remittances.

Whilst it’s not a single click, going via the Global address book is the cleanest means to do this, as it effectively links all of the common data. I’ll talk you through the simple steps in this post.

Create a supplier from a customer

  1. Find the Customer record that you wish to add a supplier for.
  2. Click on the Customer Name field. This will take you to the Party record in the Global address book:
  1. On the Action pane, click Party > New > Supplier.
    • N.B. You could also scroll to the Roles FastTab, just to double-check there isn’t already a linked Supplier.
  1. This will immediately generate a new supplier record. You will need to populate any mandatory fields, e.g. Supplier group:
  1. Now navigate back to your Customer record, open the Miscellaneous details FastTab and under Remittance > Supplier account, select your newly created Supplier.
    • N.B. You could also return to the Party record, scroll to the Roles FastTab, and see evidence of your newly-linked Supplier.

Conclusion

I hope this helps at least one person out there who might currently be creating Customer-Suppliers using a more manual approach. Although this is technically five steps (give or take), I actually think it’s quite quick and efficient.

As an aside, it does surprise me that when creating a new customer-supplier netting agreement, the Supplier account is not automatically populated with the Remittance account. Maybe that will come as this new feature settles in… or maybe there’s a good reason not to have the system do this, that someone can suggest?

There’s gold to be found in those grid views!

Our posts about making the most of data in F&O (via the interface only) have been getting a lot of love from the community, with “Filtering in D365 F&O” and “If you can’t beat ’em, get joining some tables!” proving to be among our most popular posts to date.

The Advanced filter or sort form (known as SysQueryRangeUtil to AX2012 users) brings more controls like:

We’ll cover the remainder of these in this post. First a quick reminder – you can find the Advanced filter or sort form in most views, under Options in the Action pane:

Filtering

The ability to filter on a column is fine, if you’re just looking for one value, in one field. But what if you’re trying to find all Purchase orders, (i) created for any supplier containing the word “Hardware”, (ii) created in the past 8 years, with (iii) a status of Invoiced and (vi) for the Operations department? Time for an advanced filter!

And just like that, here it is…

You’ll see that our custom filters are defined on the Range tab. You can choose to add or remove fields from the full range available (or join more, if you need to), and define the criteria for each:

  • To find any supplier containing “Hardware”, we need to use *Hardware*. Other similar shortcuts are listed here.
  • To find the Operations department financial dimension (assuming we don’t have an encyclopedic memory), we can click the ++ icon to look it up.
  • You might struggle to remember the exact name of a field – in which case you can use the standard column search feature to find it, by clicking on the column header “Field”, as shown in this animation:
(click to zoom)
  • Lastly, for the previous 8 years, we can use an advanced date query. More of these can be found in the table below:
To achieve……use thisFor example…
A date relative to nowDay (_relativeDays=0)For Tomorrow enter (Day(1)) or for Yesterday enter (Day(-1))
A range of days, relative to current dayDayRange (_relativeDaysFrom=0, _relativeDaysTo=0)For Previous 60 days and next 30 days enter (DayRange(-60,30))
A range of months, relative to current monthMonthRange (_relativeFrom=0, _relativeTo=0)For the Previous one month enter (MonthRange(-1,0))
A range of years, relative to current yearYearRange (_relativeFrom=0, _relativeTo=0)For the Previous two years enter (YearRange(-2,0)).
Any date/time before a relative dateLessThanDate (_relativeDays=0)For all dates more than a week ago, enter LessThanDate(-7)).
Any date/time after a relative dateGreaterThanDate (_relativeDays=0)For all dates more than a week ahead, enter GreaterThanDate(7)).
Any past dates/timesLessThanUtcNow ()
Any future dates/timesGreaterThanUtcNow ()
Advanced date queries in D365 F&O

Saving queries

We can save a custom query – such as the one we’ve just made – in one of two ways.

  1. Either click OK and save as a Saved view or,
  2. Stay in the SysQueryForm, pick “Query used” from the Select query dropdown, click Modify… and Save as, then type a Name and click OK:

Sorting

Now let’s say we want to sort a view by more than one column. For example, we want to sort our Purchase orders by the date they were created (in descending order) and then by Supplier name, in ascending order.

Under the sorting tab, you can add all the fields that you wish to sort by, defining the sort/search direction, and re-ordering as necessary to set your priorities. Nice!

Conclusion

Whilst it’s easy enough to Export to / Open in Excel from D365 F&O, and manipulate your data there every time you need it, why not save yourself some time by creating and saving your commonly used custom queries in the application itself?

Remember, you can also add saved views to any out-of-the-box or a custom workspace – you really can make the system work for you!

Planning items – a real world example

Many of us have used, or at least read about, Process Manufacturing and Distribution functionality in D365 F&O.

It is always noticed that some parts of this functionality are not commonly used on process manufacturing projects, but they are there for good reasons. Simply because each of them is a best fit for a specific industry.

The one under the spotlight here is Planning Items. This topic is not clear enough for many people when generically described in Microsoft documentation.

Using a real-life example to explain the topic makes much more sense. While I have many examples in mind, I am going to use the one that some friends heard from me before, the poultry industry. I think this example makes it simple even for readers with no manufacturing background.

Chickens in a coop – image credit: pixabay.com (creisi)

A planning item is a perfect fit for process industries where there are fixed or natural ratios between co-products produced together on batch order.

Let’s apply that on meat and poultry operations, where the material is livestock and the outputs are different cuts.

In the chicken example, we can process a whole chicken to get four different cuts with fixed ratios of two each. We can’t process only one cut alone; we can’t produce drumsticks for example without getting a similar quantity of the other cuts as a result of processing live hens.

Master planning considers this concept in demand and supply calculations. Even if the demand is only for a specific cut, we will have to process the whole chicken. That means, a production (batch) order will produce the four different cuts together as co-products.

Formula structure for planning item product – all images credit: pixabay.com

Let’s see how that works in production. The input for the batch order is the hen from livestock. Then, the four physical outputs will be the four different cuts. But the production order in that case is created for the whole chicken which is the planning item. So if we process 10 hens, we get 20 each for every cut.

To see that in action, let’s put our scenario in a few D365 F&O screenshots.

Starting with the item definition, we have the whole chicken defined as the planning item and this is the one we create the production order against. Then the live hen, which is the main ingredient/input from the livestock. Then we have the four co-products (cuts) in our example:

A screenshot of D365 F&O showing the Released product details form

If the batch order is manually created, it will be created against the planning item as illustrated.

When master planning (now called planning optimisation) is used, the demand will be for sellable products, which are the co-products in this scenario, and the order will be created for the planning item to produce all the co-products together. That means, even if the demand is only for drumsticks, the batch order will be created for whole chicken.

A screenshot of D365 F&O showing the Batch order form

The input/ingredient items will be on the batch order formula where we have the hen from livestock.

A screenshot of D365 F&O showing the Formula lines form

Finally, thinking about the outputs, we have four co-products for the batch order “report as finished” update. The four sellable products here are the chicken cuts. There is no mention for the planning item at “Report as finished” stage as it was only for order creation.

A screenshot of D365 F&O showing the Report as finished form

I hope this post was able to explain the idea of using planning items in a simplified real-life example to help consultants and clients utilize this great functionality when they have the right business case.

If you can’t beat ’em, get joining some tables!

You can’t always get all the information you want or need from one table or default view in F&O.

For example, viewing the Open purchase order lines form gives valuable access to all lines, across all purchase orders, that have the status “Open order”. But what would you do if you wanted to filter on something that’s not available in this view, like Cost centre?

Maybe export all the data to Excel and play with it there, as and when you need to? Or build a custom Power BI report, so you can run the report whenever you need it? Here’s another idea you may not have thought of…

Advanced filter or sort

Paul did a great post about Filtering in D365 F&O that has proved really popular with our subscriber base. We’re going to step up a gear here, and go into the Advanced filter or sort dialog, found under the Options tab in the Action Pane on most forms:

The first tab in the dialog is called Range. This is where the detail of the current filter is defined. Note the tables that are available by default:

N.B. There are some really powerful tricks that can be achieved on the Range tab – this will be the subject of another post.

Make the connection

We’re going to head to the Joins tab, where we can see the same tables and how they are linked by default to Purchase order lines:

Select the Purchase order lines table and click Add table join. You’ll be presented with a list of tables that have the potential to be joined.

Health warning: Despite being listed, not all tables join logically and this functionality may require some trial and error and generally prove tricky to get to grips with.

Scroll to find the Dimension code set. For other use cases, you might want to toggle Show details to find the specific table or detail you are looking for:

Once you’ve selected the table, click Select. You’ll be returned to the view below, where Dimension code set will now be seen:

Click OK before continuing to the next step.

Bringing it back together

Re-open the Advanced filter or sort dialog. Add a new row to the Range tab and you’ll now see the Dimension code set, or table(s) that you selected, available as an option:

Complete the filter criteria – in our case, down to the CostCenter field and a specific value of “T302”:

When we click OK, the filter will be applied, as shown below. You now have the option to save this view (e.g. “Open PO lines for CC=T302”), before adding it as a tile or list to a workspace of your choice for quick reference.

Conclusion

Table joins are standard stuff for database administrators and technical consultants, but this functionality brings the power to functional consultants and end users.

Try it out – you could save a lot of effort compared to Excel, Power BI, or worse still, over-customising your solution when out-of-the-box features like this can do exactly what you need!

If this has inspired you, please do share your own ideas or use cases in the comments.

Stand aside developers, we’ve got this!

Taking full advantage of Microsoft’s OneVersion continuous updates is predicated on the expectation that businesses, and their solutions, have primarily aligned with the adopt not adapt approach.

The F&O solution has evolved to support organisations and partners on this journey with features such as configurable business documents; addressing the almost constant need for output documents to be tailored to specific customer needs, which moves the document changes out of X++ code development and into the user interface.

Another great feature is the ability to customise the F&O forms to add new ‘custom’ fields to the user interface.

In this post I’ll be delving into the custom fields a bit more, showing how to interact with them and also additional activities required to update the supporting data entities.

Creating a custom field

In the following walkthrough, I’ll be working with a scenario of an organisation requiring the ability to internally classify and categorise their customers, which does not naturally fit within any of the existing customer record fields.

Note – This scenario is to provide context to the changes and not a specific recommendation. I appreciate the potential of ABC codes, customer groups etc, that may also address this requirement.

Navigate to Sales ledger > Customers > All customers and select ‘Personalise this page’:

The customer details screen

I have gone into more depth around the personalisation options in my post, D365 F&O – Let’s make it personal!, but for the purposes of this example, select ‘Add a field’ from the personalise ribbon and choose the form that you wish to add the field to:

The personalisation toolbar with the ‘Add a field’ option highlighted

We want to select ‘Create new field’, rather than add an existing field:

A table of the available fields to add to the customer record

This will open up a new dialog box where you can add the specifics for your new custom field:

The ‘Create new field’ setup form

A brief overview of the purposes of each selection here is as follows:

Table Name – this is the specific table that you want to customise and add the new field to. In our case is will be the ‘Customers’ table, but all tables with a direct relation to the customer record will also be listed here for selection.

Name Prefix – This is the filed name that will be prefixed to the new table field, which is previewed in the Field name box. Note: special characters, such as spaces, are not allowed.

Type – This is where you select the specific filed type. Options include; Text1, Number, Decimal, DateTime, Date, Picklist2 and Checkbox.

Label – This is the field label displayed to users on screen and should align with the Name prefix as much as possible.

For the purposes of this walkthrough the following settings were used:

An overview of the custom field settings

Once you have completed the form, select ‘Save’ and acknowledge the dialog box warning you that you will be updating the selected table.

The new field will then be displayed in the list and will be selected as default so simply, select ‘Update’ to add the new field to your form.

A table of the available fields to add to the customer record with the custom field listed

The new field will then be displayed but the forms requires a refresh to allow users to interact with changes that have been made.

Note – to save you having to repeat some of the previous steps I would recommending creating a custom view at this point, before you refresh your session.

A screenshot of the customer record with the custom field added but not editable

You’re new field should then be displayed as normal and available for selection/population:

A screenshot of the active custom field on the customer record

Data Entity Update

This step may not be required, it will depend on the purpose of the custom field. However, if there is a need to reference this externally e.g. as part of a data migration routine, export to Azure synapse for reporting etc, then the supporting data entity will need to be updated to capture the changes.

Navigate to the custom fields setup page at System administration > Setup > Custom fields:

The system administration menu path with ‘Custom Fields’ highlighted

You will initially be presented with an empty screen, but the ‘Table’ drop down will list all the tables where custom fields have been applied. Select the relevant table and custom field:

The setup screen of the custom field ‘InternalClass’

This is also the place where any changes to the custom field would be applied, including adding any required translations. However, on this case we want to review the entities related to the chosen table and ‘enable’ the field on that entity. Once the updates are made you must select ‘Apply changes’ for the them to take effect:

The InternalClass custom field being enabled on the ‘Customers V3’ data entity

Once the changes to the entities have been made the data entities must be refreshed so that the new field is available.

Navigate to System administration > Workspaces > Data management and select ‘Framework parameters’:

The framework parameters option on the data management workspace

Select the ‘Entity settings’ tab and trigger the ‘Refresh entity list’ batch job:

The refresh entity list batch job within the DMF framework parameters

You will receive a notification in the data management workspace while the entity list is being refreshed. Once the batch job has finished navigate back to the data management workspace and open up the list of data entities:

The data entities listing option on the data management workspace

Navigate to the entity on which you applied the changes and select target fields:

A data entities list with the ‘Customers V3’ entity highlighted

Finally, search for your custom field to validate that it is now part of the data entity and can be used during data import and export processes:

Target fields of the ‘Customers V3’ entity with the custom field highlighted

As simple as that, a new field can be added to the application and updates applied to any of the related data entities – with no need for technical or developer input, and absolutely no need for X++ coding.

Leveraging the standard functionality available to extend your F&O solution, rather than custom code, helps to maintain alignment with the standard toolset and reduces the risk of rework and/or overhead during your OneVersion service updates.

  1. If selecting the Text option a maximum field length must also be specified. ↩︎
  2. If selection pick list then a dynamic dialog box will appear that requires you to specify the picklist options. ↩︎

A spectacular survey of sales orders

If you’re trying to learn about a new system like D365 F&O, whether as a junior consultant or an end user, it’s not easy! First you need a sandbox environment that’s safe to “play” in, then you need a user with a security role with sufficient permissions to see and test all of the options available. Then you need the gift of time to review and test all of the functionality, so you understand all of its practical applications.

The aim of this post – and its inevitable successors – is to give you a relatively speedy walkthrough of a common area of the system, by way of screenshots from a “Contoso” sample data set. These screenshots provide a useful reference for much of the breadth of functionality available around sales orders.

The Lines view

This is the default view when you select a sales order from the grid view. From here you can see all of the constituent lines that make up a sales order. There may only be one, or there may be hundreds, but they have a single customer and sales order reference number in common.

On the default Lines view, we see a few key fields from the Header view in the Sales order header FastTab, followed by the Sales order lines themselves, and then the Line details FastTab, which we’ll cover separately in a moment.

The Header view

The Header view is where you manage all of the common aspects of the sales order, including the default financial dimensions (account segments) for all lines, as well as extensive options e.g. tax, pricing, delivery, and warehouse options, many of which can be overwritten on a line-by-line basis, back in the Lines view.

These screenshots will give you a feel of all of the default options for a sales order at the header level:

Line details

The Lines view gives you a basic level of detail and control over each line. Whilst the grid in the Lines view can be personalised, with columns added or removed by the user, depending on the admin rights applied, the real power lies in the Line details tabs beneath.

Tip: You can select multiple lines in the Sales order lines FastTab, and edit them in Line details in bulk.

Here are screenshots of the default layouts and fields of all of the Line details tabs, specifically:

  1. General – largely includes the key fields you will find in the default Sales order lines FastTab itself
  1. Setup – includes stock, VAT, returns and commissions
  1. Address – allows a different delivery address per line/lines selected
  1. Product – where we define product, stock and tracking variants, based on configured dimension groups
  1. Packing – includes bar code, packing material, and gift card options
  1. Delivery – such as estimated and actual dates, carrier, and direct delivery options
  1. Sourcing – supplier options, whether for (i) items from our organisation’s stock or (ii) items for direct delivery, straight from the supplier
  1. Price and discount – allows detailed pricing, rebate, and line-level discounts per line/lines selected
  1. Project – where the sales order is linked to a project in the Project management and accounting module
  1. Foreign trade – key elements related to export and import compliance
  1. Financial dimensions – allows line-level definition or override of header-level dimensions
    • As a reminder, financial dimensions are segments for account charts, and can include custom and entity-backed dimensions.
  1. Loads – pertaining to transportation management, showing the breakdown of individual shipments

Action Pane options

The following screenshots show all of the actions that can be taken on an individual sales order.

It’s worth remembering that in a production environment, these actions will be limited the security roles and associated permissions assigned to your user, so if you’re expecting functionality, but can’t find it, speak to your security/system administrator.

Business Central

I gave a very high level overview of the differences between D365 F&O and D365 BC in my post, Battle of the Microsoft ERP solutions. For reference, I thought it would be useful to include some screenshots of sales orders in Business Central, for a side-by-side comparison of available field sets and functionality.

Here is the default sales order form view:

And here is a feel of the menu options available:

Clearly the options are not as extensive as in D365 F&O, but are more than sufficient for smaller businesses with similar trading operations.

Which manufacturing type should you use for your project?

This is our first post by a guest contributor, Abdel-Rahman Hassan. We’d love to welcome more guest contributions – please contact us via .

At the beginning of every manufacturing project, and while D365 F&O supports both discrete and process manufacturing industries, it is very important to decide carefully which manufacturing type within the solution is the best fit for the industry.

To help explain the difference, I will split industries into three categories: Discrete Manufacturing, Process Manufacturing, and “Stuck in the Middle”.

Discrete Manufacturing

In many industries, it is obvious and easy to say, “this industry is discrete manufacturing”. This is usually the case when counted “discrete” units are produced from parts and components or even materials in machining and subassembly operations that usually ends with a final assembly operation. The discrete product can be configurable like the case in automotive where the customer can select every configuration as part of placing their order before waiting for a new car for example to be made to order.

Examples are vehicle manufacturing, appliances, electronic devices, medical devices, and producing furniture. 

A team of workers in an aircraft manufacturing facility
Image © cpphoto.com. All rights reserved

Process Manufacturing

The other obvious category is process manufacturing. This is usually the case when bulk quantities of products are produced from ingredients in mixing or blending operations with lot size considerations. Batch traceability and expiry date control are commonly, but not exclusively, used in process industries.

Catch weight is another special requirement for process manufacturing that takes place when each unit of the product has a unique weight, and the stock is controlled by two units of measure (weight unit and a discrete unit).

A single operation may produce many products including co-products and by-products. When this is the case, only process manufacturing functionality is the right fit.

Examples are; industrial gases where many gases are produced from one air separation process and iron production, where iron is the main product and slag is a by-product.

Fawley oil refinery, Hampshire, UK
Image © cpphoto.com. All rights reserved

“Stuck in the Middle”

The third category I call “Stuck in the middle”, simply because it consumes recipe ingredients in mixing, blending, or transforming operation like process, but it has one output like discrete. Here arises the confusion.

Examples are pharmaceuticals, and agricultural products where the operation makes only one output. This category usually triggers the common question “Which manufacturing type should we use?”

Unbranded liquid capsules for pharmaceutical use
Image © cpphoto.com. All rights reserved

To answer this question, please consider the industry’s potential need for any of the process manufacturing functionality elements like;

  • Formula sizes (Lot quantity)
  • Percentage yield on formulas
  • Ingredient quantity as percentage based on weight or volume
  • Alternative ingredients on formula lines
  • Scalable consumption
  • Batch ID inheritance from an ingredient to the finished product

Note, the list above is not comprehensive. I have picked the most common elements.

If there is a need for any of the above, consider using process manufacturing.

Conclusion

The first two categories are easy to recognise and hard to miss, however, the last category can be a confusing one for many manufacturing consultants. Assessing potential need for specific process functionality can be the key to decide if the Production type on the released product in D365 F&O should be “BOM” for discrete, or “Formula” for process manufacturing:

A screenshot of D365 F&O showing the Production type field on the Released product details form

Don’t take offence! How to manage personalisations

One of the most powerful features of D365 F&O is the ability to personalise and tailor the user experience. This can have huge benefits ranging from increased process efficiencies to accelerated user adoption.

However, as with any tailoring capabilities, realising their full potential often requires an element of control. Allowing too much autonomy can compromise the aim of having a consistent user experience and create blockers when it comes to training and support.

Types of Personalisation

Firstly, I think its worth a bit of a re-cap and also to call out the the different types of personalisations that are available across D365 F&O:

  • System wide – These personalisations are made centrally by users on the setup page. Examples include default legal entity at login, colour scheme, notification options etc. Mike did a great overview of these options as part of his user interface series (Navigating the D365 F&O interface (Part 2))
  • Restricted – This category of personalisations cover those changes made by users as part of their day-to-day system interaction and will most likely go unnoticed. Examples include last-run parameter values in reports, expanding/minimising fast tabs, showing/hiding details view pane etc.
  • Full – Full personalisation access covers those conscious and deliberate changes made by users while interacting with a form, table, workspace etc. They typically, although not always, require interaction with the personalisation tool bar and can include actions such as table filters, hiding columns, adding columns to grids etc. My previous post (D365 F&O – Let’s make it personal!) covers off these capabilities in more depth. It is the full access personalisations that you would most likely be looking to administer centrally.

Administration Options

There are fundamentally two angles to take when it comes to the administration and management of user personalisations; Users and Administrators; I’ll look at both. However, it is key to note that the former is predicated on having the required access rights governed by your user security role configuration.

User Options

The easiest way to view and manage your individual personalisations is by navigating to Settings > User Options:

A view of the D365 F&O home page with the user settings options listed

Then selecting Personalisation:

A screenshot of the user options within D365 F&O

This will show a screen of all system personalisations applied to your user account. It will include the system standard views and also any that you have you added. For example the screenshot below is the ‘Service Products’ view that I created in my previous post:

A screenshot showing the personalisation unique to an individual user

From this view you have a number of options:

A screenshot showing the personalisation unique to an individual user with the options ribbon highlighted
  • Export – Allows you to export the selected personalisation locally so that it can be manually imported into another environment, or to reimport at a later date if all personalisations are deleted. Selecting this options triggers a download action automatically in the background.
  • Copy to users – Allows you to copy the selected personalisation to other users in the system. Note – the copy process is based upon the user security role assignment. However, in this instance you are only able to specify the specific user accounts rather than all users with a defined security role.
  • Delete all personalisations – This is a bit of ‘Ronseal‘ button; it does exactly as it says. It will remove all personalisations for the user. If this option is desired then it is recommended you export any personalisations you wish to keep otherwise you will need to manually recreate them.
  • Reset feature callouts – Following any platform update all users will receive a notification (call out) listing the new application features that are now available to them. Once dismissed, this notification stops, but selecting this options resets that dismissal and creates the prompt again. (An easy way to annoy your users, for those of a mischievous temperament).

Admin Options

As you would expect more extensive personalisation administration options are available when being centrally managed. It is key to note here, that although in this context I am referring to a system administrator role, the duties and privileges required to maintain the following activities sit within the All roles (testing), Saved Views Administrator and Information Technology Manager roles1

Navigate to System Administration>Setup>Personalisation:

A view of the D365 F&O module navigation page with the System administration setup options listed

The personalisation settings here are considerably more extensive than those viewed from a user perspective. An overview of each is as follows:

Published Views

A view of the published saved views within system administration

This pane shows all published saved views across the system. A useful data label here when managing your views is ‘Number of roles assigned’, which can give you an indication of how extensive a saved view is used across the system.

Note – Published views are those that have been shared and/or are active and available for selection by the end users and are the default views applied when interacting with the related pages and forms.

Unpublished Views

This page mirrors the structure of the ‘Published Views’ page above. However, these are draft views which have not yet been published and are therefore not available for end users to select in the system.

Personal Views

A view of the user saved views within the D365 F&O

This page replicates the capabilities seen from an end user perspective. However, it provides a list of all user views across the system rather than those unique to that individual user account. Much like the options covered earlier these views can be exported, deleted and copied to users. However, in addition to those options you are also able to ‘Publish’ a selected view. Publishing a personal view creates a new organisation wide default view, for the security roles specified2. You also have the option to restrict the view to specific legal entities such that, for example, saved views for western Europe, could differ from those of North America.

User Settings

This is where the controls really kick in:

A screenshot of the user access settings related to system personalisation

User settings allow you to specify, at a user account level, whether personalisation is allowed and to what extent. Access levels available are ‘Full’ or ‘Restricted’ (as covered above) and can be applied at an account level or even down to specific pages. For example, it may be that you want to allow users the option to apply personalisations generally, but due to the volume of users, you want to provide a consistent user experience on the expenses list page and therefore remove the ability for this page to be personalised.

System settings

A screenshot showing the system wide personalisation settings

This is the central control for system personalisations and allows you to control whether you grant users the ability to personalise their user experience and create saved views. It also provides overarching actions such as ‘delete all personalisations’ and ‘reset all feature callouts’ that, when activated, apply system wide updates to all users and user settings.

Finally, one additional item to call out here is one of the ribbon options ‘Import Views’:

A screenshot showing the system wide personalisation settings with the Import View option selected

As mentioned at various points throughout this article you are able to export user and organisation wide views. Unsurprisingly, this option allows you to import these views. Imports can be applied to specific users, and create records in the ‘Personalised Views’ table or can be organisation wide or ‘Published’ views that apply to at a security role level across the organisation.

The personalisation views of D365 F&O are extensive and, when used correctly, can provide a great source of process efficiency for the end users. This level of flexibility can be concerning for organisations, especially when considering the drive to provide a consistent user interface. However, I personally believe that as the main consumers of the system it should be the end users that provide the primary drivers for change and standardisation when it comes to personalised views. The administration around this should be leveraged to drive consistency rather than enforce restrictions.

  1. A combination of these roles is required to fulfil all personalisation administration options. However, the standard duties and related privileges within these roles allow for these actions. ↩︎
  2. When publishing multiple views that apply to the same page only the latest published view will become the users default view. ↩︎