function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
ScottWellsScottWells 

Workflow metadata XML contains specific user ID

I've started to add workflow to our managed package, in particular for outbound message integration.  The resulting metadata XML contains a specific user ID from my dev org, so when other team members try to deploy the metadata to their orgs, it fails.

 

Obviously I can have our build scripts replace the user ID with one from each developer's own org just before deploying it, but I'm concerned about what this means for our resulting managed package as delivered to our customers.  Is there a way to abstract the specific user ID out of the externalized workflow definition for both team development and end customer deployment purposes?

 

IspitaIspita

Hi,

Abstraction of userid is a more of a design issue and the solution depends on your specific requirements.

  • One of the solution would to utiliza the $user global variable - but as I said it should resolve the design issue faced by you
  • Next approach would make use of a custom setting to store the concerned userid , your workflow can access the info fromthe custom setting somewhat  like a global variable. Please explore if this solves your issue.

Hope that helps...
ScottWellsScottWells

Thanks for the info, Ispita.  One of our developers has looked into using $user in the metadata but hasn't gotten it working yet.  He's going to continue investigating.  You had a second option that didn't seem finished.  What were your thoughts there?

 

Thanks again!
IspitaIspita

Hi,

I added the next part just check....
ScottWellsScottWells

Great, thanks!  So I'd considered that approach, but the issue I'm hitting occurs much, much earlier when I'm just trying to deploy the workflow metadata into any org other than the one in which it was created.  This is because the externalized workflow metadata contains a required attribute called integrationUser that *must* be the username of a valid user on the destination org:

 

http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_workflow.htm

 

Of course, usernames are globally unique (ignoring delegated authentication), so this means a user that's valid in one org is guaranteed not to be valid in another org.  As I mentioned, we've tried replacing that with $user but that doesn't seem to work, so we've resorted for now to a (hopefully temporary) workaround of having our ant build replace the value for integrationUser with the username of the destination org that's also used to run the other Force.com ant deployment targets, e.g., deploy-code.

 

If we can figure out how to get $user to work properly, the problem will mostly be solved, though if anyone updates the workflow in the Setup UI and needs to check in the corresponding updated metadata, the onus will be on them to make sure the file gets re-templatized with the variable.  Ideally the Setup UI would simply allow us to select either a specific user or some role or variable that's common across orgs, but as far as I can tell, it requires you to select a specific user in the current org.

 

Anyway, we'll see where we land.  Worst-case scenario, I may end up logging an issue given that they allow you to create metadata that contains org-specific information and then add that metadata to a managed package.  I would think that without some manual intervention, e.g., replacing the value for integrationUser with a variable or macro, they're effectively allowing you to create a managed package that can't be deployed!

 

Thanks again for the helpful info!

 

UPDATE: Just FYI, here's the error we get when trying to use the $User global variable:

 

Error: workflows/MyCustomObject__c.workflow(3,23):In field: integrationUser - no User named {!$User.Username} found

 

We've tried this with and without the expression syntax, i.e., $User.Username and {!$User.Username}, and in all cases it doesn't seem to be performing an expansion or replacement.  Is there some other way of expressing this that might work?