Currently it's only possible to pass objects to microflows when you call a microflow from a button. This makes it very cumbersome to make "New object" actions that pre-set some items in the object. Now you have to make a different microflow for each button and set the attribute in the MF. It would be much more convenient if buttons could use microflows with variables as inputs, and then configure the variable on the "Microflow settings" of the button.
Is this feature implemented yet?
on planned again? maybe we need a planned with date :D
Any update on this? This very usefull idea seems to be on “planned” for years now.
Would still improve daily life a lot...
Re the comment by Danny Roest: I understand this is being implemented as part of a larger change. However, I would strongly suggest to consider releasing passing the variable itself as a separate feature. This is something that I, too, have been wishing for, for years now. Just being able to simply pass an enum for example would greatly improve the reusability of microflows.
Lovely to see this is planned. Hoping to welcome this addition soon!
I am unable to recommend that our organization use Mendix at all. Hitting this was the final straw.
Hi Danny, any updates?
Please also include clickable containers, so this feature can be used for action cards as well.
Thanks for the Update @Danny Roest – I volunteer to test this feature intensively when it will be on the bleeding edge.
But I do agree. If they add this feature, it would be quite handy if it could include the page name as well.
Would be very nice if the <page title> and/or technical page name could be passed.
We have a help button on each page and had to create a MF for each page, just for calling one general MF with a parameter.
Incredible that such a fundamental feature was requested 4 years ago and it’s still not available
yes this is much needed feature, I have a use case where we have a Button on each page which calls the same MF but depending upon the page the call comes from I want to run the Validations. I could have done this very easily if I could pass the Enum or Number or String to this MF. MF I wil apply the logic accordingly the value it got as parameter.
Now I need to create one Entity say E1 and one attribute in it, create relation of this to my main Entity (used for those Pages) .
Create the object of Entity E1 and then set the attribute to particular value in MF which will load the particular page.
When Button is pressed then pass this object of Entity E1 to MF and in MF again get value from the attribute and use it accordingly. phew!!
Voted! It’s one of the most stupid/irritating limitations in Mendix.
BTW, a it seems that creating a widget with such a button is possible as a workaround.
[Edit]: No, it’s not: neither with Pluggable Widgets API (Action property cannot be fired with dynamically determined parameters) nor with Custom Widgets API (mx.data.action accepts only whole entities as calling parameters).
I am as disappointed as Andreas. This is a good idea, easy to implement (going out on a limb here, but if it is possible to pass an object, why not to pass a variable, which has a simpler structure compared to an object), this idea has a lot of votes and is indeed a pain for modelers every day. Implementing this idea makes programming in Mendix again slightly faster, which is one of the important reasons to choose Mendix over other platforms.
Looks like the status update is that it is no longer planned :-D
Any update on the timeline for this “planned” idea? It's 18 months on the planning now. :)
This would be convenient and useful. It would make sense to me to have the ability to use all of the primitive types, String, Enumeration, Integer, Boolean, etc.
YES! This is a must. It’s almost impossible to do things without a cumbersome collection of microflows, when passing a simple parameter from the UI component itself would make things so much easier.
This is really a must-have.
Currently me and some of my colleagues are working on a Mendix app, but due to the limitations described in this thread, it is ridiculously cumbersome to actually work with microflows at all, and the lack of support for parameters that aren't objects makes it impossible to reuse microflows entirely.
I really hope that support for supplying non-object parameters to microflows will be added ASAP, otherwise me and my colleagues will be forced to write almost all of our microflows as custom Java action calls.
I second Jelle's wish. Currently I'm using an object that I just created for that prupose.
This idea has been planned since 2/13/2018, so 7 months. Any idea on a timeline yet?
My team would find this especially useful for passing boolean values to microflows, but other variables, such as strings, would also be welcome.