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
Platform update 15 added back the configuration of Alerts. However this feature was delivered only partially and did not include the ability to trigger an email to be sent when the Alert was generated. The alert only appears in the Action center and it visible only if the user is logged in. One of the most important aspects of alerts is proactive monitoring of data events that would notify the right user even if not logged in. In addition to the email feature to be added back we would like the following features included:
1) Ability to select an Office 365 Group or Alias rather than a specific user to be notified. At the very least, allow the email address to be editable in the alert rather than linking only to the users email that was selected.
2) Ability to hyperlink directly back to the originating alert record and not just the list page.
3) Ability to select an email alert summarization option similar to SharePoint that would send the notification either on each change, daily, weekly or monthly. For example, if the alert was defined to send a notification of new customers added with a notification of daily, if 10 accounts were added today, all 10 would appear in a single email rather than 10 individual emails.
4) Ability to trigger a flow when the alert is sent. This gives the flexibility of generating approvals to to spawn integrations with other systems such as D365 Customer Engagement and CDS.
5) Allow email templates to be edited using MHT files (Single File Web Pages) that can be saved directly from Word and uploaded to the Template editor directly.
Still hoping we can get the Alert email feature added back in an upcoming platform update very soon.