If you are on Summer'15 Sandbox -
Process Builder processes can be successfully deployed from one environment to another using Change Sets. You need to select "Flow Definition" in the Component drop down when adding components.
Also: When you deploy the change set, the process needs to be "activated" if its not active post deployment.
When working with Opportunity Line Items in Test Classes, you need to first make sure you have a pricebook, then you need to create a product, then you need to create a pricebook entry and then you can create an Opportunity Line Item.
See the code snippets below on how to create a Opporunity Line Item in a test class.
// This is how we get the Standard ...
It turns out you can directly retrieve and update changesets directly with the Metadata API.
Via Sean Harrison:
Pro tip: U can retrieve the contents of a change set incl. manifest with the packageNames parameter on
And it really is that simple.
I made a test changeset in a sandbox with a single component:
Note the "Change Set Name" of TestCS.
No, the "contents" of the elements in a change set will reflect the most recent version of the file until it is "uploaded". That is, if you add an Apex Class to a change set, change the class and then upload the change set, the modified version will be deployed. You can see exactly what is in the changeset files by clicking the name to "view" the file, you ...
A coworker gave me this. It's a fast, easy SOQL Query that does just what I want:
SELECT Name, LastModifiedDate FROM ApexClass order by Lastmodifieddate desc
VisualForce Pages can be found with this:
SELECT Name, LastModifiedDate FROM ApexPage order by Lastmodifieddate desc
SELECT Name, LastModifiedDate FROM ApexTrigger order by ...
There are two big categories for moving changes between Salesforce orgs
Metadata API (Eclipse IDE, Migration Tool, 3rd parties)
Pro: Provide a nice native UI for picking changes that need to be moved between orgs.
Pro: When you move that change it gives you a decent representation of code coverage and progress.
Pro: Provides a ...
The deployment of communities if they are based on a Template its little different than normally how you deploy them .
Here are some of key learnings
Deploy all metadata as you normally do ,but pay special attention to below as these are community specific
I know this is an old question, but either the answer has changed or the answer was wrong.
OWD is deployed as part of the metadata of the object.
Yes Page Layouts can be included in Change Sets. If you are not seeing your changes in the target environment there are a few things you can check.
If there are new fields, you have to include the fields in the Change Set to push the fields onto the object. Page Layouts are only the UI of how a record looks. You have to push the object / field changes also. ...
When you create a change set on the source org, it is "Open'' until you upload it to a destination org.
Once you upload it to a destination org, it changes to "Closed" which means you can no longer edit it to add or remove components. However you can clone it if you want to make a quick edit and redeploy (usually when you've missed out something)
At the ...
Simple answer - it will execute every test class. If you're coming from Java environment and are hoping for recompilation/retest of only affected packages - dream on ;)
A bit more advanced answer - it will skip tests inside managed packages (if you have any), it will execute only "your" unit tests.
There were some talks about rapid deployment that'd fire ...
I work for Gearset, and we talk to lots of folks with these sorts of questions, so here are my two cents based on that :)
This answer to this question is less about the size of your org / number of users etc., and more about the makeup of the team responsible for maintaining your orgs, their technical experience level, and organizational appetite for change....
To make your new custom field visible on the target org after deploy:
Go to your personal "Setup" area - "Manage Users" - "Profiles" - and select your profile name.
You will see your profile details (quite a long page with lots of information). In our case we need "Field-Level Security" area (because of our element-type "Custom Field").
Now find the ...
The API names are, in a matter of speaking, the unique Id's for your metadata. If you change the API name in sandbox 1, sandbox 2 has no idea that you did that. So when you move the metadata to sandbox 2 it thinks it is a new field.
So to answer your question. No you can not rename API names with change sets.
If you need to do something like that I would ...
Per two known issues, W-2979657 and W-2839839:
The workaround is to set the API version of the class which makes the callout to v.33 or lower. A class with an API version of 34 or higher will inappropriately throw the callout exception when the unit test executes.
This workaround allows my minimalist reproduction code to pass the test as well as the ...
Will the changes that occurred in step #3 be deployed in the Target org?
Yes. The contents of the Change Set are not locked in until the point when it is uploaded.
Once the Change Set has been uploaded, new alterations to the metadata contained in the Change Set don't propagate to the target org. At that point, you need to clone the Change Set. You can ...
I work for Gearset and we've seen this error crop up a little in the past few days. It's a Salesforce metadata API bug where it looks like metadata from the newer version is leaked via earlier versions of the API, regardless of which API version you make your metadata retrieve request with. This means that until the bug is fixed, to successfully deploy these ...
While I thought that Change Sets could not be destructive, I just pushed a change set yesterday that removed a login IP restriction from a profile. I'm logging this with support as I feel this is a bug.
I spoke to the PM for Change Sets today and he confirmed it is working as designed. It is even documented, but I don't really think it is very clear....
When you use change sets to move components, the security doesn't automatically move unless you include the profiles you want to have security transfer for in the second section of the change set. (The section titled Profile Settings For Included Components.)
You could export Setup Audit Trail and sort/filter it in Excel for example. Not terribly convenient but it's something.
Listviews - no luck I think. And seeing that SF is keen to make Setup less and less useful (recently hidden code coverage column for example) I wouldn't count on much.
With changesets it sometimes helps to check dependencies list and ...
Every profile has tab settings for each object, so if you didn't include Profiles in your change set, then they are most likely defaulted to "Tab Hidden". In this case, they won't be visible.
In the setup menu, navigate to the profile(s) you wish to enable the tab for and edit the object for the given tab in object settings. Set the tab settings to "...
You can use the Force.com Migration Tool (ant) and write a small script to do this.
The steps would be:
ant retrieve from the source org
ant deploy to the target org
You would need somewhere to run this, such as Jenkins or Travis or anywhere that allowed you to run a recurring task.
The issue you are likely to encounter is what kind of metadata you want ...
When you upload the outbound change set a snapshot of the metadata is packaged together for deployment in the target org. After that you will need to clone the change set and upload again to pickup any subsequent changes.
You will need to deploy the necessary profiles along with the fields to carry over the field accessibility .
Field Accessibility has dependency on the profiles and change sets by default does not include profiles as well
Lightning components are available in the Lightning Component Bundle in the drop-down list of the changeset.
You can refer to this:-