Hi all,

I was curious what the views of other organisations on the large number of unused columns in the OOTB model objects.

These columns could be the legacy R11 Metafield and Key values used to support "old school" allocations. They could be for particular OOTB use cases your organisation has not adopted and therefore not populated. They could be dimensions that are just not relevant to your organisational structure, again not being populated. As new OOTB use cases are put into production, the number of dimensions now in production is growing quite large on many objects.

The easy solution is to simply add a Hide and Rename as the final pipeline step on the Master Data set and remove the columns your model does not require. This would have a benefit to overall performance and make configuration and maintenance tasks simpler as you dont have to hide columns because you hit the 75 column count limit.

Best practices for configuration however advise against "customising" OOTB Master Data sets due to friction with upgrades.

As I build out custom dimensions that provide business value to my organisation, the column count on OOTB objects is becoming increasingly difficult.

How does your organisation manage this challenge?

------------------------------
Mark Johnson
Delivery Manager - TBM Office
Origin Energy
+61 467 863 134
mark.johnson1@origin.com.au
------------------------------

#ApptioforAll

There is an automation that tries to hide those. When we run it, it seemed to hide one that it shouldn't have, which create a big mess. I believe it is fixed now, but it was quite a scare.

The wizard lists the tables with the most rows/columns first, where the gains in terms of performance would be biggest.

I agree the proliferation of tables, not just OOTB, is a problem that compounds over time.

@Mark Johnson
I figured I'd drop my thoughts here as well.  The main friction is that upon a content upgrade you'll lose your hide and rename step when you do the revert.  Maybe not needed for all tables, but for tables that have a large number of columns that aren't being used, I would simply add the step and hide the columns.  Upon upgrade you can make a branch (or take a screenshot) for reference, and then re-add the hide and rename step after you've reverted the customization to re-hide them.  It's not great, but it's the only method that works in the content lifecycle today.  I have discussed with engineering the need for configuration of this type at the model level as it's own thing, which I believe would be the long term way of handling this, essentially something like when you choose your OID Columns you can also choose which columns are not visible.