Public Profile
  • Enabled Point-in-time Change Tracking for oData Entities

    Complex system integrations commonly rely on change tracking to determine what data should be included in a given execution. Dynamics 365 F&O currently supports change tracking via the data management framework using SQL change tracking on the underlying data entity views. This meets the need when file-based recurring integrations are used to sync D365 F&O with the external system.

    However, many scenarios rely on oData endpoints for data entities in D365 F&O to perform the tasks associated with the integration. In this scenario, there is no way to execute the integration on only the data that has changed since the last execution.

    There is a need for a "point-in-time" change tracking feature that would allow an external system to call an oData endpoint to select all records that have changed since a given date/time. 

  • File Based Integration Logic App Triggers/Actions

    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:

    Inbound integrations

    • Enqueue a file as a message to a recurring integration
    • Check status of inbound file

    Outbound integrations

    • 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)
    • Download the file associated with an outbound message
    • Acknowledge the receipt of an outbound message
  • File Base Integrations - Skip Staging to Target Execution

    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.