Logic app connectors exist for oData based integrations. However, file-based integrations require the user to configure HTTP calls to execute the various triggers and actions associated with file-based integrations. The following tasks should be supported with out-of-the-box triggers and actions:
- Enqueue a file as a message to a recurring integration
- Check status of inbound file
- Dequeue an outbound message for a recurring integration
- Need two options:
- Execute automatically when file is staged...i.e. "When an outbound message is generated"
- Execute when called (i.e. for scheduled integrations)
- Need two options:
- Download the file associated with an outbound message
- Acknowledge the receipt of an outbound message
In D365 FO, If business / end user wants to navigate to next record from any list / details page, it is not possible and hence he/she must go back to list page and then select required record to see the details of it.
Solution: Same feature was available on AX 2012. If we re-introduce the same feature by re-use and tweak the code to support cloud based application would really helpful for business / end users.
It would be great to have the ability to control the accessiblity of certain DocuRef records (probably based on their type) by a grouping criterion over several users or - even better - by security roles.
More concrete: I envision this as an assignment option for security roles in form Document types with an option for read/write.
Side note: We created something similar before in AX2012 (utilizing XDS) but it turned out to be performing too badly and so we needed to remove it and tell our customers we cannot fulfil this requirement.
Recurring file-based integrations utilize data entities and the Data Management workspace to move data to the end application tables. The process is currently setup to first use SSIS to move data into the SQL staging table and then immediately execute the job to copy the data from staging to target.
There are scenarios that require user input in the staged data before executing the process to sync data from staging to target. There is currently no way to model these integration scenarios. An option should be added to a recurring data job to enabled or disable the "Copy data to target" step. When disabled, the integration could have a status called "Staged" where a user could provide input and then update the status to "Ready to copy to target." At this point the integration job could pick back up and execute the final step to copy the data.
Current infolog is showing only last 500 messages and deleting all other messages
Consider the following job
for(int i =1; i <= 502; i++) error(strFmt("line error %1", i));
for(int i =1; i <= 502; i++) info(strFmt("line info %1", i));
it will display only last 500 messages and status will be info instead of error(it can be the real case for example if we have 1000 lines in journal and first 500 contains an error – user when running journal check will see only last 500 messages and did not see an errors)
The following problem with the current implementation:
-no indication that error happened
-not all messages are displayed
-not able to easily copy all these messages to clipboard
-Message limit should be extended(let’s say to 10000) and if the message limit is reached error should be generated to inform user that not all messages are displayed
Users are definitely will not be happy with this "new infolog" as it is a base function(and it worked fine in AX2012)
Quite often current data entities don’t contain all fields from the base table (for example LedgerJournalTrans table contains 200 fields, but data entity LedgerJournalLineEntity contains only 40 fields)
And that can cause a problem, because very often client wants to use some fields that are not exists in data entity and this is not possible without development.
Can you change this behaviour – by default add all fields from the base table into the data entity
Attributes (types, groups) for Master Data (Customers, Vendors, Project contracts, Projects) and Main transaction document (Purchase Orders, Sales Orders) to reduce customisation at implementation
Thanks for extending the concept of Attributes from the Product information/Procurement module to HR module.
It will really be good to have this functionality available for Master Data as well. Although D365 has come a long way with functionality we still need to go through development effort for simple custom fields that client want on master records at implementation stage.
It will be really good to have an ATTRIBUTES fast tab, like in 'Product Configuration model' fast tab, which allows the definition of attributes for each of the master records. This will save a large amount of development during implementation where the client want a few additional fields added to the standard D365 fields with the option of making them mandatory for selection.
This can be started initially with say the CUSTOMER, VENDORS, PROJECT CONTRACTS and PROJECTS and then extended to Purchase Order and Sales Orders in the Future.