One use case is with HTTP Integrations where you may want to trigger on any change in metadata except the properties set as a result of the configuration.
You may want to update the source object with something from the HTTP response or just change a status to indicate that the change has been transferred to the external database.
If you configure Trigger to Object metadata changed without exceptions that would create a loop. The system gives a warning, so you can't do that anyway. But this means you have to list all the individual properties that should trigger rather than just the exception. The latter would be much easier :-)

BR, Karl

Having experimented with REST Object Type Connector in a proof of concept situation expecting to use the module for production some time next year I have noted these things that would be beneficial as improvements:

1. Allow Column Mappings to use the same column for multiple purposes.
   A column's content may be needed both as ObjectID and as a property value.
   
   
2. Allow configuration of how the content is handled in Column Mapping.
   If the content is to be used in a lookup property you need to be able to specify whether to look for Name or ID of the lookup value.
   If the content comes in a different language or with different terms than used in a lookup property in M-Files you need to be able to translate or use ternary rules to produce valid output.
   Sometimes you need to extract only part of the content or to split the content and place part 1 in one property and part 2 in another property.
   
   
3. Set valid default values in Logging.
   The default values in Logging creates errors that prevent you from saving the configuration until you have changed the settings of Sensitive Data Protection and defined at least one target - even when you have logging disabled.

Items 1. and 2. of the above can be handled by placing the content in a temporary/hidden property and then use Extended Auto Properties to transfer the desired values to the final properties. So it is not a showstopper, just suggestions to make it a one step operation rather than depending on multiple follow up operations.
Most of the suggested features are already available in the HTTP Integration module.

Best regards,
Karl

Well it is not quite that simple. The objects are used in automated workflows, customers are related to cases, documents related to cases and customers and so on. It would be rather difficult to manage that with a mix of temporary and ordinary object types. And users would have a really hard time finding their way in that mix.
Anyway, the vault is on premise, so that is not an obstacle. Will test Vault to Vault to see if I can make that work.

Thank you for your ideas and input.

Yes, Vault to Vault could be a possible workaround, but I think there may be a simpler option for the transition period.

You could keep the object types connected to the old ERP as temporary object types, for example Project Temp, Customer Temp and Employee Temp, and create/use the actual Project, Customer and Employee object types for the new ERP. This way, the existing synchronization with the old ERP can continue running for the business units that have not migrated yet, while the new ERP can already become the source for the final object types.

Once all business units have migrated, the temporary object types can be retired and the existing references can be aligned with the new object types based on a common identifier.

Alternatively, the separate vault + Vault to Vault approach you suggested could also work. Just keep in mind that Vault to Vault is not supported in the newer M-Files Cloud versions. If the environment is on-premises, it could still be a valid workaround for the transition period.

The challenge is in the interim period which will last at least 8 months. Obviously, after that period the new ERP shall be Master.
During the interim period changes will be made in both ERP systems to the business units running in those systems. Currently the only means to get data out the old system is through a direct OLE DB connection to M-Files, where the old ERP system is Master and the synchronized object types are registered as external object types. I was hoping to brake that lock in and use SQL Integration to pull changes into M-Files during this period.

I could perhaps solve this by creating a new vault only with the external object types from the old system and then use the Vault to Vault module to transfer any changes into the production vault. Have not tried to use Vault to Vault module yet, but it looks like it might be able to handle this challenge?

At the moment, create and the bulk update approach we have available in the HTTP Integration module is not yet supported in the SQL Integration module. This functionality is already on our roadmap, but it has not been implemented yet.

If using SQL Integration for the nightly bulk update is the only feasible option in your setup, I can check with our development team whether we could prioritize this task and potentially make it available sooner.

However, based on the setup you described, our recommendation would be to make the new ERP system the source of truth and primarily focus on synchronizing the data from the old ERP system into the new one during the transition period. M-Files could then receive all Customer, Project and Employee data from the new ERP system using HTTP Integration.

This would be the cleanest approach from the M-Files perspective, as it would give you a single source of truth throughout the transition and would not require additional changes to the M-Files integration once all business units have moved to the new ERP system in approximately eight months.

Best regards,
Nika

Client has multiple business units each having their own set of accounts in the ERP system. These have been synchronized into M-Files via a View in the ERP systems SQL database where entities from each set of accounts get joined while adding a preposition code for each business unit. So 5 sets of Customers are joined into one table in the View, and this table is then synchronized into M-Files using the standard M-Files OLE DB connector. This makes Customer an external object type, where the ERP system is the master. Similar connections are made for Projects and Employees.

Now the client is in the process of switching to a new ERP system and will do so in a gradual process where one business unit at a time switches over to the new system. This creates a situation where the old ERP system can no longer be the master database for Customers, Projects and Employees. Yet we still need to pull data from the old ERP system into M-Files and mix it with data from the new ERP system to keep all business units up to date in the vault.

There are several possible solutions in this situation:

1. Create a new separate SQL database and join data from both ERP systems into this database, and then use it as master and synchronize it with the M-Files vault.
   Connecting to the old on premise system is simple. Connecting to the new cloud based system is not at all simple - it requires tools similar to the Ext. Kit HTTP Integration.
   
   
2. Create all existing Customer, Project and Employee objects from M-Files into the new ERP system for all business units, and then make the new system the Master.
   When new objects are created we then need to make sure they are also created in the old ERP system for business units still recording their financial transactions in that system.
   We cannot pull any updates on those objects created directly in the old ERP system into M-Files because the new ERP system is now the Master in the External object type.
   
   
3. Create all new Customer, Project and Employee objects from the new ERP system into the old ERP system's database and keep that old database as Master in the External object type until all business units have switched over to the new ERP system some 8 months down the road.
   We have the means to do so via Robotic Process Automation if required.
   We would not be able to pull any status changes made in the new ERP system back into M-Files or transfer them to the old ERP system.
   
   
4. Make Customers, Projects and Employees internal object types in M-Files and set up connections to both external ERP systems.
   The client intents to initiate all new object creations directly in M-Files, and we have the means in place to transfer each object creation to the relevant external system. We can use Robotic Process Automation on the old system and HTTP Integration on the system. This way we can make sure both ERP systems have the relevant Customers, Projects and Employees for each business unit.
   However, financial records may lead to changed statuses internally in the ERP systems. A project may get closed, an employee may leave the company and so on. We need to pull those changes back into M-Files somehow. We can pull data from the new ERP system using HTTP integration. On the old system we would have to use SQL Integration in this setup. 
   As far as I can tell it is only possible to send a SQL request on one object/entity at a time and use the response to update that object in M-Files.
   I am looking for an option to run a scheduled nightly update on all Customers, Projects and Employees. Is that possible?
   
   

Extension Kit Core v26.8.0 has been released, bringing enhancements across Document AI, Word Writer, Validation, and placeholder handling.

Key updates include:

• Document AI: Classification results can now be mapped to any M-Files property, not just the class property, providing greater flexibility for different document management scenarios. In addition, IML now supports Foundry analysis alongside Azure Document Intelligence, allowing services to be combined or used separately depending on business requirements.
• Word Writer: Added support for SVG images in generated documents, enabling the use of scalable graphics while maintaining image quality.
• Validation: Improvements to validation configuration for easier setup and management.
• Custom placeholders: Expanded support for custom placeholders across all modules, including custom date formatting for more control over how date values are displayed.

👉 Read the full release notes: Release Notes

👉 Upgrade to the latest version: Download Center

Kind regards, 

Ines

Could you please share the configuration of the Orchestrator rule and the first PO rule in the chain? We’ll inspect the configuration and get back to you as soon as we can. It would also be very helpful if you could send us a screenshot of one of the objects you’re trying to set, so that we can see its structure and check for any potential issues.

Best regards,

Nika