Help us improve Gearset
We love getting feedback from our users on how we can make Gearset even better. Post your ideas for improvements, new features, and bug fixes alike, and vote for others – let us know what’s important to you.
87 results found
-
Ability to modify pieces of data before deployment of data
E.g when you want to move data from PROD to DEV there are some fields (e.g. Contract Status) that you want to move from Active to Draft. This should be a generic function also to be applied to other fields / objects.
2 votes -
Unable to import/export translations using .stf file using greaset
Currently gearset allows to deploy translations from one org to another org, however we do not have an option to do the translations using .stf file /excel for the fisrt time in any one of the org
1 vote -
Make Data Deployments Invocable (Salesforce APEX)
As a feature to enhance data deployments, make them invocable by Salesforce APEX (or other tooling) whenever a Sandbox is refreshed. Salesforce has a configuration to let the user specify an APEX trigger/class to run upon Sandbox creation. That could call the data deployments to run on the freshly minted sandbox, seeding it with data. This would enhance automation.
There are tools out there (like SFApex) that do something similar.
1 vote -
Select a set of data deployment templates and run them in order
Ability to build sequence of data load (choose a list of data load templates and have to possibility to run them automatically in sequence). The sequence can be changed.
12 votes -
enable data deployment template merge
It is currently possible to select an existing template and add new objects and data deployment logic into it then save as a new template. It would save time to enable the selection of 2 existing templates and merge them into a single one.
1 vote -
Set values on record creation for fields that can't be updated
Some objects, for example PriceBook Entry, must have their attributes set on insert as once created most of the record is not updatable, e.g. CurrencyISOCode cannot be changed on this record once it has been inserted. Providing a way to set these fields on creation, rather than a later update step, would allow these records to be deployed as currently PriceBook Entry records fail in multi-currency orgs as they are all created with the default currency causing SF to treat them as duplicates
3 votes -
Allow custom manipulations to data during a data deployment
Export the selected data source in a CSV file before deploying, in order to allow custom manipulation. Then allow the import of that CSV to destination - functioning like a more sophisticated Data loader.
3 votes -
Add a batch size option directly on Data Deployment and Data Templates
Currently we can specify the batch size for bulk data loads on Account level.
With this kind of setup we can't have two pararell jobs running on different batch sizes and we also need to memorize what batch size is required for each of my Data Templates.
It would be nice if we could do that directly on Data Deployment job and even save such setting in a Data Template.
1 vote -
Keep the same record owner between source and destination orgs.
Alternatively, allow the change of record owner before importing data to destination org.
1 vote -
Deploy Einstein Datasets from one org to the other
Copying of Salesforce objects with relations is a great feature. But this does not support Einstein datasets to be copied from one org to the other. It is critical for teams to have Einstein dataset in the lower orgs for development and testing
1 vote -
Set fields to a specific value during a data deployment
When deploying Data, it would be nice to be able to set field values. It could be just to null them or set a value. It could be part of the configuration or data masking.
14 votes -
Allow Data Deployment to filter lookup fields on fetched data
Currently, when doing a data deployment Gearset will let you know of all the referenced objects from the object you selected. What it doesn't do is the opposite of that - let you know all the objects that reference your object with a lookup.
It'd be great if we could add a filter to utilize some data pulled in a fetch/query during data deployment.
ex. field (TeamMember.ProjectLookup_c in {returned Project results in query in previous step of data deployment).
8 votes -
While configuring a data deployment, allow save after selecting objects and fields
There's no opportunity to save the data deployment settings after selecting objects and fields, and this can be quite time consuming, so if the job fails due to auth or other issues, right now, this requires the user to start over, and re-select objects and fields.
1 vote -
Support user record migration from production to sandbox or scratch orgs
New users are often created in the production org that need to be monitored and brought back to sandboxes as well. It would be great if the data deployment tool could support moving user records from prod to sandboxes or scratch orgs.
11 votes -
Add Support for Pre/Post Data Deployment Scripts
Some of my more complex data objects require that I turn off Validation Rules during deployment, then back on again after deployment.
Options that would work:
BEST: List of Validation rules under each object and and option to temporarily disable on a one-by-one basis during the deployment. A "Disable All Validation Rules During Deployment" option would be helpful if this feature is implemented.
BETTER: Ability to specify metadata xml to apply to each sobject pre and post deployment.
GOOD: Ability to specify anonymous Apex to execute pre and post deployment. This would involve a callout to the Metadata API, which…
22 votes -
Allow deployment of Email header/footer changes
Examine changes to Email Footers and allow deployment of changes.
1 vote -
Schedule data deployments
The current data deployment functionality works fine for one-off deployments, but if you are trying to keep specific data in sync across multiple orgs, the ability to schedule data deployments for a given time in the future would let you deploy on a recurring basis automatically. Becomes especially helpful when combined with the current data filtering options.
23 votes -
Support Salesforce standard Country/State Picklist Mapping for Data Masking
Right now, using the data masking feature for data deployments, the values for country and state are real values and random. There's no guarrantee that the country and state will be valid pairings.
This causes issues for orgs that use the standard Country/State picklists from Salesforce.
The goal would be that the masking feature would pull from the Saleforce default values and make sure that the state and country are valid pairings as opposed to randomizing both separately
1 voteGearset will now only use US states and “United States” for the country, meaning that the pairings are always valid.
-
Deploy data from local repository.
It would be very helpful if we could deploy data from a local repository. We have different namespaces for internal packages and it would make data migration significantly easier if we could do it from a local machine where we'd switch the namespaces.
3 votes -
Ability to update value of Reference field for a data deployment
"Select reference fields to deploy"
Ability to edit the value for the target deployment data for the reference field instead of searching for the match on the Target.
Ex. Loading Opportunities from a Source to a Target that contains 5 different record types, but when uploaded to the Target we specify the recordtypeid to one that matches a recordtypeid on the Target for the entire data load.
Similar to how the Owner reference can ignore the Target's users and default to the running user of the data deployment.
3 votes
- Don't see your idea?