X-org 2.0 - Need feedback

Hi there - 

I like a lot of the improvements in X-org 2.0. There are a few things I’d like to see improved from a UI perspective: 

1. Let me select multiple assets and move them all over at once if I want. Right now, I have to individually drag and drop each asset to select for a bundle.
2. Along the same lines, it’s hard to even know what I’ve already selected from the left pane when I’m dragging assets over one by one.
3. As always, I’d like better messaging in the product. A lot of assets say “(Dependencies can’t be Fetched)”. I’d like to see messaging as to why that is.

Thanks @spencer_engel for the feedback, these improvements are added as part of the roadmap.

@shambhawi - We have begun using Horizon rules due to the added functionality of the ‘Update CTA’ action. We are testing out all our rules in Sandbox before adding them to production. Currently, we only have Bionic Rules migration as an option, but we absolutely need Horizon Rules migration added.

Hi @JoelE - Thanks for reaching out.

The good news is we will be supporting the Horizon Rule Migration  in X-org 2.0 from our upcoming release.If you have any other feedback for X-org, please feel free to reach out.

It looks like 2.0 has complete missed out on the Delta process. 

We have generally faced A LOT of issues with both 2.0 and 1.0. One example from just yesterday was that the Case object and a bunch of related objects completely did not appear in 2.0; we had to go migrate it with 1.0. There are certain failures that will occur in 2.0 that are resolved by migrating the same thing in 1.0. 

I’m sure @sarahmiracle and @baconbomb have lots more to add here. 

Hi @gunjanm thanks for sharing the feedback for X-org 2.0, did you create any support ticket for the same, I would love to go through the details and share the same with my team so that we can effectively address that. 

We recently released the conflict resolution feature for X-org 2.0 which will internally handle the conflict(if an asset is already migrated it will either update, skip or duplicate that asset in the target based on the asset type for which the conflict has occurred). You can refer the following doc for a detailed understanding of the conflict resolution feature : link.

@shambhawi this does not replicate the Delta functionality when I am trying to validate whether I am OK to refresh sandbox or I am going to lose assets that should be migrated. 

There are many tickets across my org created re: X-org related issues. @mmayhall is our ESA and has been consolidating them. 

X-org 2.0 has some good and bad.  The bad primarily revolves around dependencies.  We have 2 sandboxes, and must develop in our “Dev Sandbox” then once that is built and working, in order to test with PMs / BAs / QA we must migrate to our “UAT Sandbox”.  Once UAT is signed off, then we move our changes into PROD.  When X-org tool breaks down and fails, or even worse, migrates “bad config” from our lower environment into PROD this causes many headaches and gnashing of teeth (and additional time spent that shouldn’t be necessary)

• When migrating objects, it appears that all dependencies for all fields (dropdown lists) are included with the migration.  These are all grayed out so no way to not migrate them
• When migrating objects, all fields are selected by default...most common use cases for migrating an object are
  • Initial creation, would migrate all - this is great with x-org 2.0
  • Adding 1 or more fields. - This is terrible in x-org 2.0.  again, having to unselect fields and not really knowing what else is migrated along is not great.  If I want to migrated the dropdown list attached to a field, then I’d migrate that.  If not migrating something would cause it to fail, then fail the migration and tell me why and that way I can choose the best course of action.
• Rule migration for Horizon rules is spotty at best.  Must have this ironed out and logs effective so that we can troubleshoot
• Still cannot trust layout migrations.  
• Logging is terrible.  Errors happen and many cases lack any details on how to fix what was wrong.  In these cases we must submit a support ticket, and in almost all cases can’t wait for ticket to be resolved and need to manually migrate config which is not good.

Where are we at on the ability to unselect dependencies in Xorg?

We should not be forced to migrate dependencies if we know they are the exact same/the values we need are there. 

By forcing us we migrate bad things into production because we could ahve created something for testing in sandbox that does not apply in production.

Shouldn’t we be final say so if both assets line up from one org to another? And if it doesn’t and we migrate throw an error.

This one issue causes so many people to not even use Xorg Beta.

@shambhawi I’ve had instances with x-org 2.0 where, when migration a solution that contains both a net new rule and fields, if both are included in the migration bundle, the rule will fail to be migrated.  The workaround there was to create two separate migration bundles, but perhaps a better solution would be for x-org 2.0 to understand the dependencies/hierarchy, and ensure the fields are added first to ensure a rule requiring that new field will migrate correctly.

Secondly, migrating a rule from sbx to prod, where prod has a version of the rule already, can at times fail to migrate.  A log is created, but the failed migration corrupts the rule.  The workaround is to rename the existing rule in prod, and migrate again from sbx with a bundle only containing that rule.  A solution to address this would be great.

I share this sentiment that a delta process should be available to review assets between orgs before knowing you’re good to refresh.

Agree here too, logging (specifically error messaging) can be better handled to guide Admins to self-resolve without requiring a support ticket, or having to figure out the issue by themselves.

@pgeorge 

Hi @Stuart 

Thank you for the feedback

1. We are looking into the issue where a bundle with Rules and new fields are failing. Will update this thread as soon as we have the fix deployed
2. For the issue where the newer version of the rule fails, can you create a support ticket for the same and we will start our analysis on it.
3. We have the Delta process in our roadmap for XOrg, but it is not scoped for this year. Once the timelines are finalized, I shall update this thread
4. We are reviewing the logs and updating them as we come across incomplete logs. Can you also share with us the logs that you find are not accurate? I will work with the team to get them updated.

Thank you

Preethi

No comment/update for mine?

Is that just something you guys aren’t willing to commit to?