Since we already have a connection between the CustTable and DirPartyTable we can utilize this to see that the DirPartyTable can connect to the LogisticsLocation and this table can connect to the LogisticsPostalAddress table. Instead we have to go through a couple different tables to find the connection. Now if we want to see how the CustTable and LogisticsAddressLocation tables you will notice that there is no direct connection between these tables. In SQL, a query to show the account number and name of customer would look like this: If we look at trying to find the connection between CustTable and DirPartyTable we can use the ERD to see there is a connection between the CustTable -> Party field and DirPartyTable -> RecId I actually host the AX 2012 ERD on my website and use it frequently. Microsoft used to host these files themselves but retired it some time ago, instead now they offer the source files on their GitHub for others to host. There are currently no ERDs for D365FO but there is one for AX 2012 which works for most objects. When data about a base object is stored in other tables normally the connection between tables is done via RecIds, but how do we determine what the connection between the table actually is? One option is to use an entity relationship diagram or ERD. How Do We Tie All of These Tables Together? If we perform the same process as above on the Customer Name field you can see that the customer name is actually stored on the DirPartyTable -> Name field.Īnd if we do the same for the Address we can see this field is actually on the LogisticsPostalAddress -> Address field. But because of database normalization this is not the case. A simple example of this are names or addresses of objects, if we continue to use the customer scenario from above you may think that the name and address of a customer exist on the CustTable as well.
This basically means that data is not duplicated in the database and that some information about an object may exist on a separate table. The reason for this is the database normalization that occurs within AX/D365FO. While the above solution seems like it is fairly straightforward not every situation is that easy. Now you are shown the ‘Form Information’ dialog and you can see this field is tied to the CustTable -> AccountNum. If you are assigned the SysAdmin role you will have an Administrative menu option, under there will be a Data Source and Data Field parameters that will tell you the table and field that ties to that form entry.įor example, if I go to a Customer and want to see which field ties to the Account field: This will cause a dialog to appear out of the right side of the screen that has additional information. The easiest method I have found is to right click on the form field (or in some cases the form field label) and going to Form Information -> Selecting the Form Name option. So how do we go about doing this? Right Click -> Form Information Want to turn on some type of audit trail tracking.Interested in applying table field level security.
There are many instances where you need to know exactly which table field is tied to an entry on a form: