Need this application as well for the same customer. Please update the Grant Type options in both applications, thank you.

I've forwarded your request to our development team and discussed the grant type limitations with them. They've confirmed we should be able to add support for the additional OAuth grant types in time for your planned August production rollout. While I can't promise an exact release date yet, the feature is now on our roadmap :)

In Postman you can select a range of different Grant Types: Authorization Code, Authorization Code (With PKCE), Implicit, Password Credentials, Client Credentials.
In Ext.Kit you can only select: Client Credentials or Password.
I had selected Authorization Code in Postman and Client Credentials in Ext.Kit - hence the different length of the tokens. If I select Client Credentials in Postman, I will get a token equivalent to the tokens from Ext.Kit, and the request is deemed unauthorized.

The optimal solution would be that Ext.Kit HTTP module is updated with options to select all of the Grant Types listed for PostMan. With that in place we should be able to simply configure Credentials on the Rule Group level and use it in all Rules in that group.

I will not need this for production until August this year. Hope you can find a way to include it in an update before that.

I wrote the initial question before I had worked my way down to all of the details regarding authorization in the Ext.Kit manual. It turns out that you can in fact configure Credentials on a Rule Group level and then use the "FromGroup" option as Credentials Source. I have tested this, and I can see that the HTTP module automatically gets a fresh token for every HTTP action, and that this new token is inserted as an Authorization header in the request.
However, the BC server still rejects the request as unauthorized.

I have gone through my configuration several times without finding anything that should cause an "unauthorized" response. So I start wondering if it could be that the request is send too soon after getting the new token meaning that the BC server has not yet registered the new token as legitimate. Would that at all be possible? And if yes, are there any method to insert a short delay between requesting the new token and actually using it?

I'm sorry for the delayed response.

I checked the Business Central documentation and it appears that you need to make a POST request to obtain an access token before sending requests to the Business Central API. Regardless of whether you are using scheduled or triggered rules, the recommended approach would be to use the Orchestration module to first execute a rule that retrieves the token, save the token to a property, and then use that property in the subsequent rule that retrieves data from Business Central.

You can find the relevant POST request example in the Microsoft documentation:

Business Central Administration Center API - Business Central | Microsoft Learn

If you need any further assistance with the configuration, please let me know.

Best regards,

Nika

Sorry for the delayed response.

For entering any protected data, such as passwords, HTTP endpoints, or similar configuration values, you will need to contact M-Files. For Cloud solutions, M-Files holds the system administrator role for all cloud vaults and is therefore responsible for managing these settings.

If you have any further questions, please don't hesitate to contact me.

Best regards,

Nika

please try the following configuration:

I tested it with the fileshare, and it should work with SFTP as well. If you need any additional instructions or run into any issues, please let me know.

Best regards,

Nika

Issue I'm having is how do I just export the one Object/Document that hit the workflow state?  I have tried to use the Document=%.% but that doesn't seem to get any results.  I can have it transfer all documents that are currently in that state but just wanting the one that triggers the event.