Share This:

The importance of testing configuration changes in a sandbox/development environment before making a change to a production environment cannot be understated.  I could post a complete article on the 'whys' behind Sandboxes, however this post is geared for organizations who are past the 'why use a sandbox' phase.

 

This post will assist you with sandbox concepts and scenarios specific to the Salesforce.com platform and the Remedyforce application.  It also important to note that this post is not all encompassing.  Look forward to additional whitepapers and posts in the near future on the topic!

 

Main Topics

 

 

Basic ORG Concepts

Lets start off with some basic concepts and terminology related to the ORGs.

 

"Production ORG"

This is the environment where you and your users will log into on a regular basis to use the Salesforce and Remedyforce functionality that you have purchased.  The ORG is the platform that the Remedyforce application runs on.  You may have purchased your Production ORG from Salesforce originally and then purchased Remedyforce on top of that, or you may have purchased Remedyforce which comes with a Salesforce Production ORG.

 

"Sandbox ORG"

When the term "Sandbox" is used we are talking about a separate ORG on the Salesforce.com platform that is a copy (in some form) of your Production ORG.  Production ORG's can have multiple associated Sandbox ORGs.  For example, you could have a Production ORG that has 3 Sandboxes associated to it - possibly one for different business units or application development teams.  The default purchase of Remedyforce provides you with one "Developer Sandbox".  You may purchase more Sandboxes and/or different types of Sandboxes.  We will discuss the different types of Sandboxes a bit later. 

 

Once a Sandbox is created it is a copy of your Production ORG.  You can then make changes to Production and/or a Sandbox that will not impact the other (until you are ready for it to).  The Sandboxes are completely separate ORGs at this point.  We will discuss promoting changes from Sandbox to Production a bit later as well.

 

Each Sandbox may be 'refreshed'; which deletes the Sandbox ORG and creates a new copy from Production.  Refreshing a Sandbox will re-copy the Production ORG into the new Sandbox.  There are limits on how often that you can refresh a Sandbox; refer to the chart on Understanding Sandbox Environment Types for Refresh Intervals.

 

"Remedyforce"

Remedyforce is a 'managed package' that runs on top of an ORG (Sandbox and/or Production).

 

The 3 concepts above are very important in understanding Sandboxes and how you will use them.  A good basic analogy so far is a computer.  Each Production/Sandbox ORG is the Windows/Mac/Linux machine and operating system.  Remedyforce is one of your applications that you run on that machine.

 

Quick Quiz

 

Q1: If you have three Sandboxes, how many total ORGs do you have?

A1: Four.  Your 1 Production ORG and 3 Sandbox ORGs total 4 different ORGs.

 

Q2: Of the four ORGs mentioned in A1, the Production ORG had Remedyforce installed on it prior to the Sandboxes being created.  How many installs of Remedyforce do you have running?

A2: Four.  Sandboxes are a copy of your Production ORG at the time that it is created.  Since Remedyforce was on the Production ORG when the Sandboxes were created, the Sandboxes will also be running Remedyforce - unless you uninstalled Remedyforce on a Sandbox after it was created.

 

Q3: Of the four ORGs mentioned in A1, the Production ORG did not have Remedyforce installed on it prior to the Sandboxes being created.  After the Sandboxes were created you installed Remedyforce onto the Production ORG.  How many installs of Remedyforce do you have running?

A3: One.  Since Sandboxes are a copy of your Production ORG at the time that it was created, the only ORG with Remedyforce on it is the one that you specifically installed Remedyforce onto.

 

Q4: Of the four ORGs mentioned in A1, the Production ORG did not have Remedyforce installed on it prior to the Sandboxes being created.  After the Sandboxes were created you installed Remedyforce onto the Production ORG and refreshed one of the Sandboxes.  How many installs of Remedyforce do you have running?

A4:Two.  Since Sandboxes are a copy of your Production ORG at the time that it was created, and refreshing a Sandbox re-copies from Production, the ORGs that would have Remedyforce on it would be the Production ORG and the refreshed Sandbox ORG.

    

 

Data Types

Lets shift a little bit now and understand what type of data is inside of an ORG.  In regards to Remedyforce, there are three main types of data that we need to understand.  Understanding these data types will help later on with how you migrate something from a Sandbox ORG to your Production ORG.

 

Type #1: ORG Metadata managed by Remedyforce

Examples of this type of data are the out-of-the-box fields, field sets, and workflows that come preconfigured in the ORG as part of the Remedyforce installation.  This type of data is added to the ORG by the Remedyforce installer and is considered 'managed' by the Remedyforce application.

 

Type #2: ORG Custom Metadata

Examples of this type of data are custom fields, custom field sets, and custom workflows that you create.  This metadata could be a copy of Type #1 metadata and then changed for your needs or it could simply be brand new metadata that you create.  This metadata may or may not be used in Remedyforce based on how you configure it, but at the core this metadata was created and is managed in the ORG by .

 

Type #3: Data

There are two examples of this type of data:

    • One example would be the individual records/tickets/cases such as Incidents, Change Requests, or Configuration Items.
    • Another example would be what is often referred to as the 'configuration data' for Remedyforce.  Examples are categories, templates, service request definitions, SLA's, status, impact, urgency, priority, etc.  Note that this type of data, while similar, is different from Type #2.  Type #2 is ORG related configurations and Type #3 is Remedyforce related configurations.

 

 

Moving Data From a Sandbox to Production

Now lets talk about why understanding those three data types are important.  Depending on what data you are trying to configure in a Sandbox and then move to Production, you will have to potentially use one or more different methods.  Here are some examples:

 

  • Moving Type #1 data from Sandbox to Production using Pentaho Migration packages. Not only can you move configurations from one environment to another, you can move configurations from one organization to another. The Pentaho packages provided by BMC are created using two types of files, Transformation Files (KJT) and Job Files (KJB). The transformation files contain all the scripts and connection entries and the job files run multiple transformation files rending the process easy and timely.
  • Moving Type #2 data from Sandbox to Production can be accomplished through Change Sets.  Change Sets are relatively easy to configure and can be a very powerful feature to use.  A complete list of ORG items that can be moved via Change Sets can be found at Components Available in Change Sets.
  • Moving Type #3 data from Sandbox to Production cannot be accomplished through Change Sets but can through data migration utilities such as Data Loader, Pentaho, or other importing tools.

 

Quick Quiz

 

Q1: You wish to make some changes in a Sandbox before rolling it out to your Production ORG.  In the Sandbox you edit a default Remedyforce field set, add two new statuses, edit three priorities, and add 20 new categories.  How will you move these to Production once you are ready?

A1: For the field set metadata, since you edited an out-of-the-box Remedyforce field set, you will need to manually make the change in the Production ORG.  For the other items, you could manually make the changes in the Production ORG or use Pentaho to promote the data from Sandbox to Production.

 

 

Sandbox Types and Details

Earlier I mentioned that Sandboxes are a copy of your Production ORG, but not all Sandboxes are created or function equally. Salesforce has a great help page dedicated to Understanding Sandbox Environment Types and is where the bulk of the following information will come from.  Here are some high level bullet points to consider:

 

  • Your purchase of Remedyforce from BMC comes with one "Developer Sandbox".  If you purchase from BMC you can also purchase as many "Full Sandbox" ORGs as you wish.
  • Existing Salesforce.com customers may already have additional Sandboxes as part of your pre-Remedyforce contract with Salesforce.  Salesforce can also sell you additional types of Sandboxes besides "Developer" or "Full".
  • A "Developer Sandbox" will copy the Production ORGs "metadata" (types #1 and #2 defined above), but not the "data" (type #3 defined above).
  • A "Full Sandbox" will give you the option of copying everything from the Production ORG - including "data".
  • You can refresh a "Developer Sandbox" every 24 hours and a "Full Sandbox" once every 29 days, so it is important to plan these refreshes with your maintenance and change windows.  Ensure that you are taking into consideration the maintenance that both Salesforce and BMC have planned for your ORG.  Salesforce posts maintenance announcements on trust.salesforce.com and BMC posts Remedyforce maintenance schedules on BMC Communities.

 

 

 

Hopefully this post has provided deeper insight into using Remedyforce with Salesforce Sandboxes.  As always, stay tuned to BMC Communities for additional blog posts, whitepapers, and other valuable information.  Also be sure to check out the Remedyforce Wiki and Salesforce Help for additional resources.

 

Have a great week!

 

Regards,

Joshua Green