You just need to deploy the field and the related object. For instance if you have a Lookup, you need to deploy the look up and the target object of the lookup (if the object its not already on production).
Best way I think is to use change sets ( a good video here: https://www.youtube.com/watch?v=2qy8oV99iAM)
Regards,
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.
You just need to deploy the field and the related object. For instance if you have a Lookup, you need to deploy the look up and the target object of the lookup (if the object its not already on production).
Best way I think is to use change sets ( a good video here: https://www.youtube.com/watch?v=2qy8oV99iAM)
Regards,
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.
You are fortunate if you have access to all the sandbox types. Here is one way to use them. If you don't have all types avaiable, you will need to combine some activities.
1) Full Sandbox - Fully testing changes against real data before promoting to production. This may include user acceptance testing. All changes must go through this sandbox. If multiple admins/developers are working on overlapping areas, this is the place where changes get merged. Force.com IDE can be used to compare changes by separate developers of the same apex code.
2) Partial Data Sandbox - This is a new sandbox type and I am not quite sure what the intention was. Probably just a cheaper alternative to a full sandbox. If you have a full sandbox, then partial data sandbox sounds like a good place for user training for new features, new employees, etc. Having real data can really help with training. Also, possibly a place to work on integration changes since it can hold quite a bit of real data.
3) Developer - A place to work through solutions to new requirements. The main idea is to keep random experimentation out of the full sandbox. It there are multiple admins/developers, each one should get their own so that they don't trample on each others work (until they deploy to the full sandbox).
4) Developer Pro - The main difference between this and Developer is the amount of data that can be stored. It also grabs some product data from production. If those two things are important, use this one. Otherwise, it's interchangeble with Developer.
OR
you move these new items over from Sandbox to Production using Change Sets. You only put the items you want to move over into the Change Set. Change Sets are completely different than a "Refresh".
You just need to deploy the field and the related object. For instance if you have a Lookup, you need to deploy the look up and the target object of the lookup (if the object its not already on production).
Best way I think is to use change sets ( a good video here: https://www.youtube.com/watch?v=2qy8oV99iAM)
Regards,
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.
All Answers
You just need to deploy the field and the related object. For instance if you have a Lookup, you need to deploy the look up and the target object of the lookup (if the object its not already on production).
Best way I think is to use change sets ( a good video here: https://www.youtube.com/watch?v=2qy8oV99iAM)
Regards,
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.
You are fortunate if you have access to all the sandbox types. Here is one way to use them. If you don't have all types avaiable, you will need to combine some activities.
1) Full Sandbox - Fully testing changes against real data before promoting to production. This may include user acceptance testing. All changes must go through this sandbox. If multiple admins/developers are working on overlapping areas, this is the place where changes get merged. Force.com IDE can be used to compare changes by separate developers of the same apex code.
2) Partial Data Sandbox - This is a new sandbox type and I am not quite sure what the intention was. Probably just a cheaper alternative to a full sandbox. If you have a full sandbox, then partial data sandbox sounds like a good place for user training for new features, new employees, etc. Having real data can really help with training. Also, possibly a place to work on integration changes since it can hold quite a bit of real data.
3) Developer - A place to work through solutions to new requirements. The main idea is to keep random experimentation out of the full sandbox. It there are multiple admins/developers, each one should get their own so that they don't trample on each others work (until they deploy to the full sandbox).
4) Developer Pro - The main difference between this and Developer is the amount of data that can be stored. It also grabs some product data from production. If those two things are important, use this one. Otherwise, it's interchangeble with Developer.
OR
you move these new items over from Sandbox to Production using Change Sets. You only put the items you want to move over into the Change Set. Change Sets are completely different than a "Refresh".
https://na1.salesforce.com/help/doc/en/changesets.htm