Yes, it is sometimes a good idea to hard-code values (for example, while learning Apex or Process Builder or hard code Pie value i.e. 3.14), but there’s no simple rule as to when; it depends completely on context. If you’re hard coding the value of the earth’s gravitational constant, no one’s going to care. If you hard code the record ID (Queue, Group or Salesforce record Id, etc.), you’re in for trouble. Time and time again, I see Apex code, Flows or Processes that contains hard-coded Ids, whether it’s the Description field, a user ID, or even a group ID, etc. The problem with hard coding IDs is that any changes need to be made to the Flow or Process itself, test again, and then deploy to production org. The record IDs can change, for example between a sandbox and a production environment. It might be possible that a queue (Dupe Management) has different ID in a sandbox and a Production org. Let’s start with a business use case

Business Use case

Donna Serdula is working as System administrator at Universal Containers. She has received a requirement from higher management whenever an account is created for Industry Not For Profit, auto create a case and assign it to Nonprofit Experts queue to verify organization’s nonprofit status. 

Solution of above business requirement

To solve the above business requirement, first of all, we have to create a queue as shown in the following screenshot 

Nonprofit Experts – Queue

Now you can refer the Queue id while creating a case through Process Builder.

Create a record – Process action

The problem with this approach (Hard-coding queue ID) is, If you are developing in the Sandbox, the IDs of the newly created Queue will change when you get to Production, and you have to do the rework. 

–> As per Salesforce best practice, everyone will suggest you don’t Hardcode IDs, Query for them. 

It is always good to follow Salesforce best practices where possible. At the moment Process Builder doesn’t allow to query and save the outcome (means record ID, field value, etc.) in a variable, even you can’t save newly created case ID (case created through Create a Record – process action) in a variable. 

So what next? How to avoid Hard coding of IDs in Processes? 

Some of the ways to avoid hard-coding are as follows

1. Custom Label: – Custom labels are custom text values that can be accessed from Apex classes, Visualforce pages, Flows, Process Builder or Lightning components. While deploying a custom label, its data also gets deployed. To avoid the unexpected behavior make sure to update the custom label value post deployment.   
2. Custom Setting: – Custom Settings are variables that you use in your code but set and modify outside of your code. Custom settings are cached. It is especially useful to store information that will be often accessed from Apex code or Flow as it will perform better than a custom object. It does not count against SOQL limits when fetched. You can use hierarchy custom settings in Process Builder directly, not list custom settings. The custom setting doesn’t bring data over when you deploy them.
3. Custom Metadata Type: – Custom Metadata Types are similar to Custom Settings. While deploying a custom metadata type, its data also gets deployed. Currently, custom metadata types are not supported in Process Builder. You may want to vote on this idea Use Custom Metadata Types in Process Builder, Formulas/Validation Rules. 

 Perform the following instructions to solve the above business requirement

1.  Click on  Setup | Build | Create | Custom Labels
2. Click on New Custom Labels, it will open the new window for you. Now create a new custom label to store the queue (Nonprofit experts) Id, as shown in the following screenshot

Custom Label – To store Queue Id

3.  Our next task is to create a Process Builder on the Account object to create a case, if account industry = Not For Profit. Click on Name | Setup | App Setup | Create | Workflows & Approvals | Process Builder
4. To create a new process from scratch, click on the New Button available on Process Management page. A popup will appear where you have to enter the Name (Use Create case for Non-Profit Accounts as name), API Name and Description as shown in the below screenshot

Define Process Properties

–> Now you can create a process that another process can invoke. With invocable processes, you can reuse sections of your processes. Build one invocable process, call it from multiple processes or from multiple action groups in the same process. You can invoke processes with objects that share at least one unique ID. For example, in the Account and Contact objects, the AccountId field is unique to Account and also used by Contact. You can create an invocable process that updates a Contact record. Then you can invoke it from:

• A process that updates an Account record’s billing address
• A process that adds an Account status 

To create an invocable process, select It’s invoked by another process for The process starts when. For current business scenario, we have selected A record changes, as shown in the preceding screenshot. 

5. Click on Object node to add object and then select Account object. For the entry criteria, Select only when a record is created, as shown in the below screenshot. Once done, click on the Save button

Evaluation Criteria

6. The next task is to add Process Criteria. To do this click on Add Criteria, enter Name, Type of action and set filter conditions as shown in the following screenshot.

•  [Account].Industry Equals Picklist Not For Profit

Process Criteria

7. The next step is to add an Immediate action to Process. For this select Action Type Create a Record, Use Field Picker to map the fields, as shown in the following screenshot

Add action – Create a Record

The next step is to map Owner ID field with a custom label. To do so select Formula for Type, as shown in the preceding screenshot. Then click on Build a Formula text and select System Variable dialog a shown in the following screenshot  

Create a Formula – Process Builder

It will open a popup where you have to select $Label and then select label Nonprofit Experts QueueID, as shown in the following screenshot 

Choose a Custom Label

Once you’re done click on Choose button. In the end, formula for Owner ID field should look like the following screenshot 

Once you’re done click on Use this Formula button. Add one more row to associate new case with account record, At the end Create a Record action should look like the following screenshot 

8. Once done, click on the Save button, it will redirect you to Process canvas. Finally, the Process will look like the following screenshot

Don’t forget to active the Process by clicking on the Activate button.

It’s time to test the Process

1) Navigate to the Account tab, and create a new account for Industry Not For profit, as shown in the following screenshot 

New Not for Profit account

Once done, click on the Save button. It will open account detail page and check case related list as shown in the following screenshot

Proof of concept

Note: –  I will suggest you guys, implement this first on your developer/sandbox org, test it and then move it to production.

We’re here!!!

Join us (co-hosts Rakesh Gupta, Jennifer Lee, and David Litton) on 07th April at 3-4pm ET for the 16th webinar of Salesforce Automation Hour! – automationhour.com

This is a Webinar series focused on bringing process automation solutions to you with a Q&A session at the end where we will answer your process automation questions you submit via chat or in our success community Salesforce Automation

Register now:  http://bit.ly/IanGotts040717 (Presenter: – Ian Gotts) 04/07/17 3-4pm ET
Register now:  http://bit.ly/ZacOtero042117 (Presenter: – Zac Otero) 04/21/17 3-4pm ET
Register now:  http://bit.ly/BHinners050217 (Presenter: – MVP Bonny Hinners) 05/02/17 3-4pm ET

Join the Salesforce Automation Hour Success Community to post your questions:  https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A0000004glD