 Perry Inaldo
Perry Inaldo
    
          
          
        My feedback
10 results found
- 
2 votes Perry Inaldo
    
 shared this idea
           · Perry Inaldo
    
 shared this idea
           ·
- 
7 votesThanks for the suggestion Celio. We think this should be possible to do and are doing some background work into how to manage and display this. More details to come soon. Thanks, 
 Jason. Perry Inaldo
    
 supported this idea
           · Perry Inaldo
    
 supported this idea
           ·
- 
70 votesThanks for the suggestion. We have plans to improve the way the diff viewer handles changes and whitespace in the future, though it’s not currently under development. Thanks, 
 Jason. Perry Inaldo
    
 supported this idea
           · Perry Inaldo
    
 supported this idea
           ·
- 
108 votesHello. A large number of commenters requested the ability to carry out value replacements as part of metadata deployments. Gearset now offers a feature called Environment Variables that lets you do just that! It works with both manual and CI deployments and lets you target either a Salesforce org or a Git repo of your choice. And, for a number of key metadata types, you can even specify the exact 'field' where the replacement should take place. If you have any feedback on the Environment Variables feature, please open a new feature request or simply let us know in the in-app chat. Thank you for upvoting this feature request and we hope that you will find the Environment Variables feature useful. Blog post: https://gearset.com/blog/environment-variables/ Support doc: https://docs.gearset.com/en/articles/5557015-using-environment-variables-in-gearset  Perry Inaldo
    
 supported this idea
           · Perry Inaldo
    
 supported this idea
           ·
- 
4 votes Perry Inaldo
    
 supported this idea
           · Perry Inaldo
    
 supported this idea
           ·An error occurred while saving the comment 
- 
11 votes Perry Inaldo
    
 shared this idea
           · Perry Inaldo
    
 shared this idea
           ·
- 
6 votes Perry Inaldo
    
 shared this idea
           · Perry Inaldo
    
 shared this idea
           ·
- 
14 votesIf we implemented this and it was only able to search metadata from that point in time onwards, would that be useful or would it be confusing to communicate in the UI? An error occurred while saving the comment  Perry Inaldo
    
 commented Perry Inaldo
    
 commentedWe do not have a VCS and it would be nice to be able to search GS with what was deployed to see the history of changes on metadata.  Perry Inaldo
    
 supported this idea
           · Perry Inaldo
    
 supported this idea
           ·
- 
52 votes Perry Inaldo
    
 supported this idea
           · Perry Inaldo
    
 supported this idea
           ·
- 
82 votesMerging differences between Apex classes and VisualForce pages is difficult to do automatically due to the understanding required by the developer. For differences between two orgs in other object types, Gearset helps you sidestep that with our granular comparison results. This blog post explains more: https://gearset.com/blog/merging-salesforce-metadata  Perry Inaldo
    
 supported this idea
           · Perry Inaldo
    
 supported this idea
           ·An error occurred while saving the comment  Perry Inaldo
    
 commented Perry Inaldo
    
 commentedI would like to add to this topic the need to be able to select lines of code to include in the deployment. We do not have VCS yet and many developers working on their not often refreshed sandbox makes the comparison harder and we tend to overwrite someone's code or changes already deployed in production. My workaround is very long by comparing 2 orgs, validate and then download the XML, to be edited outside of Gearset, and use the edited XML as the base in another comparison for deployment. This would tremendously help us if we are able to select the lines of code instead of the whole file, especially in Profiles, permissions, apex. 
 
          
Not sure if this is different than what you are asking but I would also like to have an account level access something like the org level delegate access of Comparison, Validation, Deployment. This way you can set what a team member can only do. Not everyone should have a deployment access, thus preventing breaking code they accidentally deploy.