Skip to content

Justin Lyon

My feedback

19 results found

  1. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 
  2. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 
  3. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Justin Lyon commented  · 

    This would be huge to have this option.

    This aligns with the way Salesforce treats a permission set xml as a single unit. And this is the whole reason why permission sets are preferred now over profiles, because profiles came apart into so many pieces and you had to combine so many metadata types to retrieve (and then deploy) profile changes.

    Additionally my end users will commonly use the "Select All" checkbox in Salesforce to add fls to every permission set in the SF provided "short list". When this happens, the only way to fix it is to back out the fls one at a time on the extra permission sets in the sandbox because Gearset currently aggregates all perm set changes by custom field permission - I can't select which permission sets I want to include in my changes.

    Justin Lyon supported this idea  · 
  4. 13 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 
  5. 10 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon supported this idea  · 
  6. 21 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon supported this idea  · 
  7. 3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Justin Lyon commented  · 

    Gearset has already done the hard work of identifying that there are 0 component changes to be deployed. So under this scenario it should just NOT deploy into the target if that target is a sandbox or prod.

    This happens most commonly when I am making updates to keep the repository in sync with the sandboxes, but the sandboxes already have the changes. Or if I'm making maintenance updates on our git repo that have no Salesforce components in them.

    Justin Lyon shared this idea  · 
  8. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 
  9. 3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon supported this idea  · 
  10. 18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Justin Lyon commented  · 

    I'm shamelessly going to link to another user voice request on scripting that I think should be at the top of the list for anything pre/post scripting related.

    I can appreciate the value this request is looking for, but I think we'll see a lot more value if this second, lower voted request get's traction.

    https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/41847037-bash-scripting

  11. 5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Justin Lyon commented  · 

    Not only would I like to see bash scripting, but also extend this to allow us to run npm scripts out of the package.json.

    An error occurred while saving the comment
    Justin Lyon commented  · 

    Adding pre and post deployment scripting that can also selectively execute by environment or by sandbox/vcs target types would be an awesome super power.

    This would allow teams to craft their own scripts that pre/post deactivate/activate validation rules/triggers/custom metadata, or run linting on pre commit. Or Delete Old Flow Versions and Flow Interviews in post deploy. It would be huge.

    Justin Lyon supported this idea  · 
  12. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Justin Lyon commented  · 

    I think this is a challenge for Gearset Releases because this happened despite following the pipeline process using the Expanded Branch Model.

    1. Create Feature Branch
    2. Compare and Commit
    3. Create PR against UAT
    4. Promote to UAT
    5. Add to Release

    -- UAT Feedback captured from business --

    6. Push change to Feature Branch
    7. Create PR against UAT
    8. Promote to UAT

    -- Gearset syncs gs-pipeline/feature_-_uat to _-_main
    -- Gearset syncs gs-pipeline/feature_-_main to gs-release/ branch

    It was UAT feedback changes that occurred on steps 6, 7, & 8 that ended up getting rejected and spun out again as new PRs against PROD.

    Justin Lyon shared this idea  · 
  13. 10 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon supported this idea  · 
  14. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 
  15. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 
  16. 5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Justin Lyon commented  · 

    +1 for branch pattern matching, this would be on par with our peers outside the salesforce platform using established tools like Azure DevOps, GitHub Actions, Jenkins, BitBucket Pipelines, GCP

    Justin Lyon supported this idea  · 
  17. 15 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Justin Lyon commented  · 

    This would also be an important feature for those of us that want to break up the happy soup into various packages. I might not want to check in a whole object for one of my packages, but there would certainly be a collection of custom fields that I want to check-in.

    Justin Lyon supported this idea  · 
  18. 3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 
  19. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Justin Lyon shared this idea  · 

Feedback and Knowledge Base