Flow designed to execute spoke on specific MID Server fails as the runtime MID Server is a different one. <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Custom Flow that selects MID Server "A" to execute spoke fails as the runtime MID Server is MID Server "B". It turns out both MID Servers are configured as a MID Server Cluster PRB1731697 (Won't fix) was found that explains that when when a MID Server is a member of a MID Server Cluster, the platform runtime overrides any step-level or connection-level "Specific MID Server" selection at execution time. Instead of routing to the individually configured MID Server, the system elevates the request to the cluster level and applies the cluster's load-balancing logic — meaning either cluster member may be selected regardless of what is specified in the Flow configuration. The most reliable resolution is to remove the target MID Server from the cluster. Once it is no longer a cluster member, the "Specific MID Server" configuration in the Flow will be honored at runtime as expected.