After some extremely busy weeks, I finally found some time to continue my blogs related to Microsoft Dynamics 365 for Finance and Operations and Microsoft Flow. In this part, I will elaborate on the action Get a record.
In this part of the Flow blog series, I will discuss the Delete action for the Microsoft Dynamics 365 for Finance and Operations connector. I posted a blog before on this action. See: How Microsoft Flow can help on data corrections in Dynamics 365 for Finance and Operations.
On my two previous blogs, I got some great feedback. Thank you all for the kind words. It will help me continue writing blogs. There is still more to write about Microsoft Flow. In this part, I will explain the Update a record action for the Dynamics 365 for Finance and Operations connector.
My previous blog was an introduction how to start using Microsoft Flow with the Microsoft Dynamics 365 for Finance and Operations connector. In this episode, I will elaborate on the Create a record action. How can you use this action and I will provide some related tips. E.g. how use line numbers which should be incremented?
Create record action
The template which I used in my previous blog used the create record action also. A screenshot of the basic part shows the most important fields for the Vendors entity.
As you can see, you have to specify the environment as well as the entity to use. When these to values are specified, you will see a list of mandatory fields (marked with red asterisk). When the entity is company specific, you will also see a dataAreaId field. The Vendor account field in this example is mandatory in Microsoft Dynamics 365, but not in the entity. If you provide a value, it will be used as vendor ID. If you leave it blank, it will use logic to retrieve a number from the number sequence.
Use the create record action
When you want to create a Flow, you always have to start with a trigger. Triggers can be based on an event like a new mail message has been received. The previous blog used a recurrence. You can also install Flow on your mobile device and start Flows with a button.
When the trigger has been inserted, you can continue with actions. Usually, you would read content from a certain application and bring data automated to a destination. One destination is the action Create record on the Dynamics 365 for Operations connector. When you add a new action, you can search with keywords for the correct action. You can use e.g. Operations, Dynamics 365 or a combination to narrow down the results. At the time of writing this blog, there is a trigger for Dynamics 365 for Finance and Operations in preview. I will elaborate about it in a future blog post.
When you inserted the Create record action, you can choose the correct environment. Usually you will first choose a test or demo environment before actually use a production instance. The second required field is the entity. Flow will list all public entities. Some names are quite easy to find, like Vendors. When you don’t know the name of the entity or cannot guess the correct name, you can open the form in Dynamics 365 and use the function Open in Excel. When the Excel sheet has been downloaded, you can then look in the design mode which entity is used.
In some cases, there are multiple entities for the same table, but there is a version difference. For the vendors, there is a V2 version available. It is recommended to use the highest version number. Older versions will get depreciated in the future.
In some cases, you get a error when typing an entity name. The connector is trying to find the correct entity as you type. When you have only a part of a keyword, it will mention that it could not find the entity. It is a bit annoying, but you can ignore this error when you are still in the process of selecting your entity.
When you have selected the correct entity, there will be some mandatory fields listed. Then a field for the company (dataAreaId). It will then have a key field in case it is not mandatory. In this example, the vendor account number is not mandatory, but it is mandatory within Dynamics 365 itself. The reason for not having it mandatory is that you can leave this field empty. In that case, it will try to pick up a number from the number sequence. If you did not provide an account number and the number sequence is set to be manually, the flow execution will result in an error.
To be able to use all other fields, you can click the option Show advanced options. It will list all other attributes in a non-alphabetical order. It would be nice if the field list has a certain structure, but in the current way, it is possible to map all fields.
When you completed the flow, you can test and activate your task.
How to use line numbers in Flow?
A common question is how to use line numbers in Flow? They are not automatically filled when you are using Flow or other Odata based tools to insert records. Flow can support in incremented integers by using Variable actions.
Directly after the trigger, you can add Initialize variabele actions. You need to declare all variables that will be used in your Flow. For line numbers, you can use the Integer Type. The first value can be set to the Value 1 (or another value according to your preference).
For a flow, e.g. importing purchase order lines from an Excel file, you can use the line numbers. There could be an option to increment with 1, 10 or other steps for the line numbering. How to use the line numbering an increment the value for the next line can be seen in the next screenshot.
The purchase lines create record action has the variable LineNumber mapped as input for the LineNumber field. Then after the create action, the LineNumber will be inremented with the Value 1 in a Increment variable action. In this way, you can use line numbers provided by Flow if the business logic in Dynamics 365 for Finance and Operations is not automatically populate the Line number field.
Use values from other Dynamics 365 actions
When you look at the screenshot above, you can notice that the purchase order number and data area fields are filled with Dynamics 365 fields. In this Flow, I did use a purchase order header entity to insert a new header record first. When the purchase order has been inserted, you can re-use the values in the Flow for other entity actions or providing a notification which order was inserted.
The next part (3) will inform you about the Dynamics 365 for Finance and Operations update action in Flow.
That’s all for now. Till next time!
After spending some time with building some automation for Microsoft Dynamics 365 for Finance and Operations with Microsoft Flow, it would be a good timing to write some blogs. The intention is to help you getting started understanding the Microsoft Flow tool and build your own business automations. (meer…)
You hardy can have missed the announcements from Microsoft how they will continue delivering updates for Microsoft Dynamics 365 for Finance and Operations. In fact the full Dynamics 365 product range will be on the same update cadence. Depending if you are already running Microsoft Dynamics 365 or not there are changes which you also need to prepare for yourself.
When using the cloud version of Microsoft Dynamics 365 for Finance and Operations, there are certain tasks which are a bit more cumbersome if you compare it with the freedom you have when running the application on-premise. When there was a need for data correction, we were used to quickly develop a job or class with x++ logic to repair data. In certain cases, we could deliver a list with identification numbers which was then used as looping to correct or delete only certain records. In this post I will explain how you can be more agile creating correction scripts using Microsoft Flow.
When I initially learned AX 2012, before it got released, I was quite enthusiastic about the security changes and the organization hierarchies. Then also I learned about the eXtensible Data Security (XDS) concept. While working on one of my first AX2012 implementations, I also had to do a presentation for a Dutch community. The topic was about the Organizations and Hierarchies. While preparing the session, I suddenly got the idea to combine security role assignments, organizational hierarchies and XDS. After the presentation, I lost the demo and objects used at that time. For another presentation during the Summit EMEA in Dublin this year, also about organizational hierarchies, I decided to create a new demo. In a former blog, you can find the link for downloading the objects for this example. (Extensible Data Security examples for Microsoft Dynamics)
In this blog, I will explain you how this “Secure by retail channel” works functionally and technically.
In this post, I will continue explaining the examples created with eXtensible Data Security. In this part, I will explain how I did think of a solution for restricting warehouse access for users. There were a lot of questions on forums in the past about how to secure this. So, for a presentation on the Summit EMEA in Dublin this year, I decided to step into the challenges that comes with securing access to warehouses and related tables like inventory journals or purchase orders. I created a demo which will be covered in this part of the XDS blog series. In addition, this is a good example how to deal with different assignment of groupings per user without creating a policy per group or user.
In my last blog, I shared some code examples for eXtensible Data Security (XDS). In this post, I will explain how it works and also introduce a V2 version which will be more advanced in determine which legal entities will be visible for the user.