Branden,

It's not possible to add stuff to microflows from runtime actions. I.m interested though what your use case is, maybe there is a different solution for this case.

The plausibility of your suggestion hinges entirely on what you want the split to do. If you loop over the potential reference selector objects you will can model a unique split based on the new object. However, that's only half the battle. I'm assuming that you want to implement unique behavior for each split. If so; how is the modeler supposed to know what 'maybe' is supposed to do unless you model it?

Branden,

Having thought about this for a bit, I think you may need to revisit your model. In my understanding, enumerations are intended for lists of things that are likely to change infrequently, if at all, like states or counties. Things that will change frequently should be maintained in an entity inside of Mendix.

As to being able to perform activities with newly created objects in an entity, perhaps a model like this could work:

• Create a set of granular microflows for the basic activities performed in your business, like adding a customer or shipping a product
• Create an enumeration that has one entry for each of these basic activities
• Add that enumeration as an attribute on an entity that will be used to determine what basic activities will be performed for a newly created object
• Now when you create a new object, you can also present the user with the opportunity to decide what basic activities will be performed for that object

Consider the following example:

• You have the following possible activities that could be performed when a new customer is created: perform credit check on customer, assign dedicated salesperson to customer, send customer welcome packet, place outgoing call to customer to welcome them and require credit card payments from customer.
• You create a self contained microflow for each of these activities
• You have a Customer Type entity in your domain model.
• You have a Customer Activity enumeration with one entry for each of the activities listed above
• You create a Customer Type / Activity entity in your domain model
• When a user creates a new customer type, you present them with a window that enables them to pick one or more of the activities to be performed, and perhaps the sequence to perform them in
• After this setup is complete, when a new customer is created and a customer type is chosen for that customer, you can have a microflow that will execute the microflows for the granular activities for the newly created customer

Just one way to accomplish what it sounds like you want to accomplish.

Mike