Custom actions
When a post-refresh step is specific to you, write it as an Apex class and use it in workflows like a built-in action. Custom actions need the Enterprise plan on the Hub.
The class
Extend btcveles.Veles.Action in the org where the workflow will run (the sandbox, or the Hub if you push the class with your deployments):
apex
global class WarmSearchIndexAction extends btcveles.Veles.Action {
global override String getName() {
return 'WarmSearchIndex';
}
global override String getLabel() {
return 'Warm search index';
}
global override btcveles.Veles.ActionResult execute(
Map<String, Object> parameters
) {
Integer batchSize = Integer.valueOf(parameters.get('batchSize'));
// your work here
return btcveles.Veles.ActionResult.success(
'Warmed ' + batchSize + ' records'
);
}
}getName()is the identifier Veles stores in the workflow. Keep it stable.execute(parameters)receives the parameters entered in the action form, with merge fields already resolved. Return a result with one of the statusesSUCCESS,FAILED,PARTIAL_SUCCESS,WARNING,INFOorPENDING; the message shows in the Activity Log.- Override
requiresSalesforceAuth()to returntruewhen the action calls the org's own REST APIs; Veles then providessend(HttpRequest)with authentication handled, for relative paths such as/services/data/v62.0/.... - Override
getParameterHelp()to describe your parameters in the action form.
Register it
Actions > Custom Actions, type the Class Name, click Validate Action (expect Valid Veles.Action implementation) and then Register Action. From now on the class appears in the Action Class list of every workflow. A custom action registered on the Hub is carried to children by the push, marked Synced from Hub.
What happens below Enterprise
The class is still listed, with an (Enterprise) suffix, and registering it is refused with the plan named. A workflow that already contains a custom step logs one line, not available on your plan, for that step and runs the built-in steps around it.
