As Rob would say, these are definitely have your cake and eat it too types of items but would love to see the following features:
1) Custom Actions - Similar to custom components with a builder, would be very useful to write custom actions that would appear in the list of available actions within the action framework. This can all be done via snippets so the functionality exists today, however having custom actions would enable a declarative approach to more common actions that take place once the custom action is written.
2) Action Conditions - Similar to rendering conditions, would be very helpful to have one of the below. For situations where a large number of actions are invoked based on a triggering event (e.g. button press), there could be a slight deviation of which actions should trigger based on some condition. This is possible currently by having two buttons each conditionally rendered based on that condition. However, in the case where a lot of the actions are in both buttons, this creates a support/maintenance issue and increases risk when changes are needed. I know there is talk about a “shared/global” action sequence concept that might help along these lines but having one of the below would allow configuration to be in once place instead of multiple.
a) Conditions on an action that would dictate whether or not an action should be invoked
b) Conditional Branching that would move through subsequent actions based on conditional evaluation (e.g. if condition is true do this sequence of actions else do this other sequence of actions).
Note - The current workaround I have used for this is to have an action that runs a snippet that evaluates the condition I need and returns true in one case and false in another. This allows me to use the “onerror” branch for “else” operations, however I can only get away with this approach when the “else” is very simple subsequent actions (e.g. page redirect).
Thank you!
Wish List Items - Action Conditions and Custom Actions
+13
+13Love these ideas, Barry. We have talked about Action Conditions in the past, definitely makes sense, but I had not considered Custom Actions before. Under the hood we are allowing Component Types to register custom actions that are valid for Action Sequence invocations initiated from within the Component (and we’re not ready to document this yet), but I think that adding additional global Custom Actions, or page-specific Custom Actions, would make sense.
+3Barry and I have connected through email on this but I wanted to provide a wider update to the community.
We delivered conditional branching for actions in the Brooklyn release - see the Action Framework > Logic documentation for more details.
We also plan to provide the ability to create and register custom actions (and formulas, and other things), but we have some work that we need to do first in order to accomplish this. We want to be able to support packaging of components, formulas, actions, themes etc. in a way that allows them to be versioned. We need to do the work to support versioning and packaging before we do the work to manage registration of custom actions and other things, since it will likely affect how the latter gets implemented. Additionally, we are exploring ways to better expose actions in the App Composer UI, because - as you’ve probably noticed - it’s already hard to find the action you want in the current action picker.
I don’t have a target release for this yet, so I’m going to leave the status as Under Consideration until I do.
+3Actually, Barry, with your permission, I’d like to mark this suggestion as completed and leave your related idea, Custom Action Support, open as it is basically the part that I just talked about.
I could merge that one with this one, but it’s got more content regarding the custom actions so I’d like to maintain that history.
+13Hi Shannon -
I’m good with closing this one out and leaving the Custom Action Support as the tracking issue moving forward. As you mention, it has a lot more meat to it so makes sense to use that one.
Regarding Action conditions, I do have a other posts regarding enhancements to this functionality. In case you haven’t seen them yet (or for others who might be interested), they are located here and here.
Lastly, I would be remiss if I didn’t thank you for checking first before closing/merging. Often times companies mark items as closed/fixed without first checking with the customer who reported it to see if it’s really fixed/implemented. Closing the proverbial loop is always a best practice so thank you, greatly appreciated!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.