2

I’m working with the new “New Flow” option available in milestone actions (Entitlements and Milestones – Winter ’25 feature). According to the release notes, the process to add a flow is:

Open the milestone from an entitlement process. Click Add Actions and select New Flow to add the autolaunched flow. Go to Flow Builder to customize and activate this action.

From my testing, it seems:

  • You can't create a flow directly from setup and then assign it to milestone action.
  • You must create the flow directly from the milestone action UI for it to be selectable.

This becomes a problem when deploying to another environment. The flow itself deploys successfully and is available in the target org, but it can't be selected for the milestone action. The only way to link it is to recreate the flow from the “New Flow” action in the target org.

I've inspected the Entitlement Process metadata and found the following structure:

  1. The EntitlementProcess metadata has a milestione field of type EntitlementProcessMilestoneItem.
  2. This type contains a timeTriggers field of type EntitlementProcessMilestoneTrigger.
  3. This in turn has an actions field of type WorkflowActionReference.
  4. The WorkflowActionReference type has a required type field of type WorkflowActionType.
  5. One of the available values of type is FlowAction, which corresponds to the autolaunched flow.

It looks like the association between milestone actions and flows is stored in a way that only recognizes flows created from that specific context, rather than any existing autolaunched flow.

IMPORTANTE NOTE (Let's continue with strange behaviours):

  • Flows aren't shared between different Entitlement Processes. In other words, the flow created from an action in a Milestone associated with an Entitlement Process will only be available for other actions in other Milestones that are associated with the same Entitlement Process.
  • Flows can only be selected if they are assigned to an action in a Milestone.If the flow is unassigned from all Milestone actions, it will no longer be available for selection again (even though it still exists). It has to be rebuilt in order to be assigned again.

Is this a known limitation?

Is there any metadata or deployment approach that allows using an already-deployed flow in a milestone action without having to recreate it manually?

Improve this question
4
  • I don't have an answer, but I recently opened a case asking if you could use an existing Flow in this feature, and you cannot. You must create the "flow" in the Milestone UI and it's only visible there. Given the serious limitation you already mentioned, I would stay away from this "Flow but not a flow" entity and try to make workarounds using actual Flows. Commented Aug 11 at 16:20
  • 1
    I've posted an idea on IdeaExchange. Let's see if it gets enough relevance to make it part of the Salesforce Roadmap. Commented Aug 12 at 7:29
  • Thanks, I voted for it. Commented Aug 12 at 14:50
  • how does the Flow metadata differ between milestone actions versus from normal flow UX Builder? Wondering if you could coerce the former to look like the latter in your VCS Commented Aug 18 at 20:18

1 Answer 1

Reset to default
2

In addition to the manual work of creating the flows directly in every environment, the current behavior also breaks CI/CD workflows. Milestone actions only allow selecting flows that were originally created from the “New Flow” button inside the action itself. Flows created from Setup or deployed aren’t selectable, even if they’re active and compatible.

In my case, this became evident when we deployed flows as part of a Work Item for a new project feature. Since these flows weren’t created from the milestone action, they couldn’t be linked to it. To work around this, we deleted the deployed flows in our test environment, recreated them manually via the “New Flow” option in the milestone action, and then linked them. Initially, this forced us to remove those flows from our repository so deployments wouldn’t overwrite them.

After considering this, I suspected that Salesforce might treat manually created flows differently once they already exist: if a flow exists in the org and is later updated via deployment, it might keep its references. I tested this hypothesis with three checks:

  1. The manually created flow is updated when deployed again.
  2. The link to the milestone actions remains intact after deployment.
  3. The flow remains selectable for new milestone actions in the UI.

All three checks passed, so the conclusion is that the most reliable workaround is to create the flows manually in the target environment via the milestone action “New Flow” option, link them to the appropriate actions, and then add them to source control. From then on, deployments will update them without breaking the association, and they will remain selectable for other milestone actions.

Improve this answer
2
  • Have you encountered any similar behavior with Classic Approval Process Flow Actions? Commented Nov 6 at 15:53
  • Not something I’ve encountered so far, but I’ll keep it in mind and share if I find anything relevant. Commented Nov 8 at 19:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.