User email are masked in Sandboxes and we can mask Contact emails as part of the data deployment. This still leaves the Org Wide addresses as valid emails. If there is automation that is generating emails related to the data that is loaded, they will be delivered to the Org Wide Addresses.

It would be useful if the same script that is deactivating validation rules could set email deliverability to systems emails at the same time.

In the even that email deliverability was set to all emails in the Sandbox and not adjusted before the data deployment we would have an extra safety net to prevent emails from going out.

It's great that we can set filter visibility now to Only Me or to share with Team. It would be nice, especially for larger teams, to have another way to organize them either with tags, folders, sub teams or groups.

Example: 1 Scrum Team may have 10-15 filters they maintain and use, and another group of users on a team also have 5 or so they use. Both can see all 20, and this adds up fast.

Feels like being able to group users together could also have other benefits like mass assigning access to orgs (for deployment, validation, comparison) vs doing it per each user individually

When compare source and target, sometimes u do an educated decision to NOT select something, and then selecting the rest of the items. Then if the compare results saved as a Draft Deployment, u may return back to it, and do a refresh for the comparison. In this case Gearset would kindly save all of the selected items. But for items that were not selected by the user, not they are mixed up with the new differences. So user have to remember, that this particular item he did not select intentinally, but this item that is not selected is a new difference.

It would be nice to have an additional capability to mark "not selected" items to "not deploy". So if I refresh the comparison, i would be able to identify "not deploy" items from new difference.

In the past we had troubles deploying reports via CI, they were not showing/deploying, the workaround was to enable the filter to include all reports. This works to solve that, but now I am looking at including more into the repo and start using delete actions in the CI jobs as well. The downside is that because we have to have all reports in the filter, the CI job will delete reports created by users in non-private folders. A freedom we want to give certain users in Production.

What would be an epic enhancement (and solve this challenge) is if you could decide to do delete actions per metadata type. Then I'd configure delete actions for everything except Reports and List Views for example.

some time you have got misplaced your excel report password now you have not any option the manner to cast off password from excel 2016 so do not worry and you can skip GSTECH and use very marvolous software program application program this name is EXCEL Password healing software software program.Due to the fact this software is most beneficial to liberate your excel record with out dropping information of your excel report.This software program program program making use of 3 brilliant approach to unfastened up your excel document Brute strain assault,mask assault and dictionary assault.This software program software program suppot the all model of excel document. Its walking technique is just too smart, MS Excel customer can do snap recovery of any shape of Excel password

Read more: https://recoverywithgstech.wixsite.com/bestsoftwares/post/how-to-remove-password-from-excel-2016

Gearset allows the selection of multiple External ID's in an Upsert operation as part of a Data Deployment.

However, the system implements an 'AND' combination across all the external ID's specified on the object.
Effectively, ALL external ID's need to be present on the target side for the match to be identified and record upserted. If all external ID's are not present, the system performs an Insert on the target org.

Please allow an 'OR' combination across multiple External ID's. Arguably, this should be the default option, but at the very least, a user needs the ability to decide how they want multiple external ID's to be interpreted.

Gearset currently uses OAuth to connect to GitHub, and the way that works is that the OAuth connections have permissions to all repositories that my user has access to, which from a security perspective is a problem, because if the github key were ever compromised, it would provide very broad access to customers GitHub organizations.

Security teams would feel much better with the ability to limit the scope of access to just one repo instead of all the repos that my GitHub user has access to, which can be accomplished by creating a Github App which can be installed for an individual repo.

Quote from GitHub docs: "GitHub Apps are the officially recommended way to integrate with GitHub because they offer many advantages over a pure OAuth-based integration"

https://docs.github.com/en/developers/apps/getting-started-with-apps/migrating-oauth-apps-to-github-apps

https://docs.github.com/en/developers/apps/getting-started-with-apps/differences-between-github-apps-and-oauth-apps