6

I have 4 flows as part of my mdapi deployment from sfdx to my packaging org. I get an error on all 4 flows when trying to deploy.

  • I've tried deactivating them first, no go.
  • I've tried saving them as new versions, nada.
  • I've tried saving them as new flows, bupkis.

I successfully deployed these flows in earlier packaging orgs, but now something must have gotten corrupted -- though that doesn't make sense that I'd get corruption on all four flows...

I thought maybe it was some dependency issue, so I deployed the rest of the package without the flows (successful) and then tried redeploying with the flows. No bueno.

SFDX is frustratingly cryptic in the error message:

Deployment finished in 27000ms

=== Result
Status:  Failed
jobid:  0Aff400000clzBnCAI
Completed:  2018-05-19T23:02:51.000Z
Component errors:  4
Components deployed:  360
Components total:  364
Tests errors:  0
Tests completed:  0
Tests total:  0
Check only: false

=== Component Failures [4]
TYPE   FILE                                              NAME                       PROBLEM
─────  ────────────────────────────────────────────────  ─────────────────────────  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────
Error  mdapioutput/flows/Intake_to_Assigned_User-1.flow  Intake_to_Assigned_User-1  An unexpected error occurred. Please include this ErrorId if you contact support: 525159581-113493 (1495769207)
Error  mdapioutput/flows/Intake_to_Queue-1.flow          Intake_to_Queue-1          An unexpected error occurred. Please include this ErrorId if you contact support: 525159581-113494 (1495769207)
Error  mdapioutput/flows/New_to_Assigned_User-1.flow     New_to_Assigned_User-1     An unexpected error occurred. Please include this ErrorId if you contact support: 525159581-113495 (1495769207)
Error  mdapioutput/flows/New_to_Queue-1.flow             New_to_Queue-1             An unexpected error occurred. Please include this ErrorId if you contact support: 525159581-113496 (1495769207)

ERROR:  The metadata deploy operation failed.

I haven't been about to find any discussion on flows and sfdx deploy. Any ideas?

3

As the error says, you need to contact Support. Once any file has an error of the Internal Server Error variety, all remaining files will also have that same error. There really is (most likely) only one broken flow in the bunch; you might try deploying them one at a time to find the offending file. I can ask my contacts to tell me what the error maps to, but without your file, there's little hope of telling you specifically what's wrong with your file. Again, to be clear, you need to contact Support to get this cleared up.

  • @sfdxfox, thanks. I've filed a case on it. I have a new theory based on the history of deployments with these same flows. I'll be testing this morning. I have successfully deployed these flows to multiple packaging orgs during development/testing -- but my process was to deploy, then set up the namespace when I started packaging. The issue I'm having is when I'm deploying to the org with my "gold" namespace already established. I'll report back... – PatMcClellan__c May 20 '18 at 15:11
  • @PatMcClellan__c Sounds like a namespace bug then. Hopefully they'll get it over to R&D. – sfdcfox May 20 '18 at 15:48
2

Here's what I've learned through trial and error:

1) I am unable to deploy my flows to a partner dev org that already has a namespace, as reported in my post here yesterday.

2) I am able to deploy to a partner dev org with no namespace. The links to platform events are intact when deployed. However....

3) When you set a namespace on that org, it breaks the links to the platform events.

4) When I repaired the links to the platform events and tried to save the flows, I got the error message. I just Shift-Command-M to open the message window in flows, I was able to determine that a number of other custom fields in custom objects were inaccessible by the flows. I had to adjust field level security for a number of the custom fields in the custom objects to make them visible to the flow. I don't understand this because the flows are run by the system, not by users or admins, so I would expect the system to be able to see these fields, regardless of field-level security. When all the troublesome fields were repaired, I was able to save the flows.

Summary: namespace appears to break some, but not all, links to custom fields and custom objects (including platform events) in flows. SFDX cannot deploy when these errors are present.

Workaround: deploy to non-namespaced org, add namespace, repair flows, move on. Not ideal, but I can move forward.


UPDATE: thx sfdcfox for the comment about perm set when editing the flows. I tested, and you're exactly right.

In my previous post, I reported that Flows lose connection to the Platform Event parameters and to some custom fields in custom objects. I can now clarify.

As previously reported, the flows will not deploy to a namespaced dev org. I can deploy to a non-namespaced dev org, and then subsequently add the namespace. When the namespace is added, the links to the Platform Event parameters are lost.

I had incorrectly assumed that the Platform Event links issue and the broken links to custom fields/custom objects were related, and caused by the namespace.

The issue I was having with the missing custom fields turns out NOT to be related to namespace, but to the fact that when I was editing the flows and resaving them, I had not assigned myself the permission set needed to access the custom fields. This is really strange, as the flows are run at a system level, not by a user, so I wouldn't expect the perm set to matter -- but it does, apparently.

So, current workflow needs to be:

  1. deploy mdapi with flows to non-namespaced org
  2. assign the necessary perm set to access custom objects/fields
  3. apply the namespace
  4. edit the flows to re-establish the links to platform events
  • The flow engine compiles based on the current user's field and object level security, which is... odd. I'm not sure why it does this, but for now, you'll have to accept the fact, or perhaps include the system admin profile in your artifact tree, such that the field level security will be pushed as well. – sfdcfox May 21 '18 at 19:40
  • So, assign myself the perm set for the custom objects before I open the flows? OK, that's an easy workaround. I'll test to see if that works. – PatMcClellan__c May 21 '18 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.