X-org 2.0 - Need feedback

shambhawi
Rank
Badge

I am Shambhawi, currently working as the product manager for the X-org team.Our current focus is to solve the existing pain points for the X-org tool and make the user experience better.
If someone is interested in sharing the pain points related to X-org please feel free to comment here.
Things that we are looking for :

1. What has been your biggest concern while using X-org tool
2. What would you want to change about the tool(x-org 2.0)
3. Any feature request for the X-org tool

Thank you in advance,
Shambhawi

10 replies

spencer_engel
Rank
Userlevel 7
Badge +2

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.
shambhawi
Rank
Badge

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

J
Rank

@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.

shambhawi
Rank
Badge

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.

gunjanm
Rank
Userlevel 7
Badge +11

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. 

Gunjan
shambhawi
Rank
Badge

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. 

shambhawi
Rank
Badge

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

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.



 

gunjanm
Rank
Userlevel 7
Badge +11

@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. 

Gunjan
W
Rank
Userlevel 5
Badge

 

andybuchanan
Rank
Userlevel 1
Badge

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.
Andy

Reply


Terms & ConditionsCookie settings