Allow for line item subset to be more than just number formatted

AnaplanIdeas

 

Description of the enhancement required:

Line Item Subsets are often used to build filter modules, as an alternative to using the Show/Hide functionality. Using a Boolean against a Line Item Subset on a filter module makes it very easy to select which columns should be shown or hidden on a dashboard.

 

An example of the enhancement:
It would be great if you could add Line Items of all formats (not just number) to a Line Item Subset for this purpose. Perhaps you could utilize the Line Item Subset type field to setup certain Line Item Subsets to allow both number/non-number formats.

AnaplanIdeas

daniel_harman

The restriction that the format is the same across all line items in a line item subset should apply only if a COLLECT() formula is used.

alexpavel

Hi, 

I totally understand the constraints of COLLECT() function.

But why COLLECT() should work only on NUMERIC linet items ? Why do not apply the summary property of non-numeric Line items ( ANY for boolean, FIRSTNONBLANK for boolean. texts , etc..)

 

In the below discussion there is also other reason that line-items subsets could be used also for non-numeric line items: create a dynamic filter to show-hide line-items in dashboard:

 

https://community.anaplan.com/t5/Best-Practices-Forum/Dynamically-filtering-the-line-items-columns-in-a-dashboard/td-p/33401

 

Thanks

Alex

 

daniel_harman

Hi Alex,

COLLECT() could work on any line item subset where all line items in the subset are of the same semantic* type. The summary type of the source line item would be used where applicable.

* Semantic type adds more detail to the datatype where applicable, i.e. which list, or which period granularity.
e.g. a line item formatted as list A has datatype 'List', and semantic type 'List: A'.

Dan

alexpavel

Thanks Dan for explanation. 

 

However, my first goal into accepting in line items subset the non-numerical formatted line-items was to be able to create a system to dynamically show-hide columns  in a dashboard, similar with grouping columns from Excel and not to be able to use the COLLECT() function. 🙂

 

Now this can be done only for numeric line-items creating a separate module with the subset and boolean line-items, but I think it would be really cool to have it also for non-numeric line-items

 

For me it would be acceptable that for non-numeric line-items selected in a subset, if used in a module with COLLECT() function, to receive the result 0 or null or 'NaN'.

 

What do you think ?

Thanks

Alex

 

 

 

 

DavidSmith

We could use this in cases where COLLECT() is not used

• Version Formulae
• DCA on line items (commonly requested since DCA was launched)
• Used for mapping with LOOKUP and SUM to map between lists members and line items

 

dmitrii.mamaev

DavidSmith I know that now you are a part of Core team, so I hope the development will be speed up multiply times..

 

This feature is "Must have" one. 

Collect() function shouldn't disable the functionality of whole model.

There are a lot of situations when LIS is used without Collect() 

For example it's neccesary for dashboard design.

 

Last status change was  ‎07-18-2018 12:26 PM to: Concidered for future roadmap. It was practicaly year and a half ago.

Whas is actual status for this idea?

 

helennie

Bump for any update on the status of this idea.

 

Line Item Subsets are so versatile, but are severely hamstrung by only being able to include numeric line items.

DavidSmith

@helennie 

I am looking at the big list of requests, so I'll definitely add it into the mix

David

alexpavel

Any update about this?  It would be really useful to make showing/hiding columns dynamically in a page valid not only for numerical table grids...

dan.fleming

Agree with @alexpavel  - any update?

Ingilavicus

Indeed would be extremely interested in any update regarding the possibility of getting this feature. 

 

Maybe @rob_marshall, would have any insights for the curious bunch here? 

 

Andris

rob_marshall

@Ingilavicus 

 

I wish I had an update, but sadly I do not.

alexpavel

Any update on this? 

It's really a pity not having the possibility to create dynamic filters for non-numeric line-items. 

 

I think it would be acceptable that, if a line-item subset would contain also non-numeric line-items the COLLECT() will return an error. COLLECT() to be used exclusively only if ALL line-items from the line-item subset are numeric. 

 

Another use case:  Having a combination list + Month. There are non-numeric line-items in the module which define the properties of the combi list and numeric line-items to input data. 

 

It is impossible to create a dynamic layout where you need to show in columns the properties and the 12 months. This unbalanced layout structure cannot be create in NUX and in a Saved View (in classic) you can do it manually and hard-coded.  (see below picture). 

 

Having the possibility to create filters on non-numeric line-items would solve this issue. 

 

 

 

It would be really nice to solve this as soon as possible. 

 

Alex. 

Maik

I strongly support Alex' opinion in this regard. Especially in the new UX we absolutely need a solution for dynamic filtering of non-numeric line items. The easiest way would be with line item subsets for those line items. If this is not an option (and it looks like it as this idea exists for more than 3 years and was not delivered) is there any practical workaround?

NoahJ

I will throw some more support on this request - allowing Line Item Subsets to include more than just numerica data would greatly increase their functionality. I am very surprised that there has not been any update on this, despite the great number of comments and support here. It is a feature request that continues to be relevant, and could be combined with the newest User Experience features to make for some amazing and intuitive presentation of information. 

 

Ideally the COLLECT function could be used to aggregate multiple data types (throwing an error if there were different data types in the LIS, and requiring an aggregation method to be specified for non-numeric formats), but even if COLLECT could only be used on number format data it would still be a great win. 

ramonito

Any update on this? this will greatly help in doing a dynamic show/hide based on what dimension item is selected.. why don't we just return an error/ or not allow if the collect() function is used on a non numeric line item?

david.savarin

Or depending on the line item format where the collect() is used, just return the default value (blank, 0, false) for non compatible lis elements.

jepley

RE-upping this.

Using line item subsets to filter line items in and out of a view is very helpful in giving users the ability to change their view in a single click; however developers are limited to Number-formatted line items. Giving the ability to add non-numerical items to a LISS and limiting the format of a line item dimensionalized by the LISS to boolean would open up a developers ability to give Users more control over dynamic views.

Limiting which line items can be formatted by LISS to number and boolean would assist in cleanliness.

kjacokes

Bumping this up.

The value to Anaplan here is that customers are spending $ on consulting hours to solve things like filtering non-numeric line items, instead of spending $ on more Anaplan connected planning functionality.

There are definitely design paths that would not require this functionality, but they have their own draw-backs, and after careful consideration of alternatives, we're in a position where filtering non-numeric line items would be valuable.

Casting my vote that a limited form of including line items in line item subsets be possible so that we can dynamically filter line items based on those line item subsets.

Kevin

girishramrao

I too Support this requirement. Desperately needed feature.

PaulFitzmartin

An update from Anaplan would be appreciated. This has been outstanding for 5 years now.

DavidEdwards

154 upvotes and five years with no action. Great customer service.

mikem

This would be a great feature to add

kjacokes

I know some of y'all are frustrated by this. I myself really, really want to see this, but I'm sort of glad we haven't gotten it yet? Because if I really thought about what I'd have to give up to get it, I'm not sure it'd make me happy.

Reading between the lines, I suspect that this isn't getting prioritized attention because:

(a) tons of R&D resources are being poured into DMS, AI, and other areas where they will have a massive positive impact on customers, and so the risk-adjusted return on time invested into this feature is probably a lot lower than the other things on the Anaplan product roadmap. See (b) below for what I mean by risk-adjusted ROI.

(b) COLLECT() functionality is already black magic for numeric data (it does what I haven't seen any other technology do…Essbase, Adaptive, Pigment) and it's already pretty wild we can turn line items (measures) containing numbers into a new dimension. And modifying that to support text requires opening up the heart of Anaplan — the core — and that introduces all sorts of risks and constraints. Risks being erosion of performance of every single Anaplan model across every customer. Constraints being the physical size of the servers running Anaplan cores.

And we know from Rob Marshall that text data in models is the enemy (sometimes), so extending all of that magic to support text would probably erode performance, and consume valuable memory on the Anaplan core machines. In contrast, many enhancements over the last 5 years haven't required modifying the Anaplan core in a significant way (DMS, Workflow, CloudWorks, New UX, PlanIQ). I'm intentionally leaving Polaris off of that list because that's entails a redesigned core, but had the benefit of getting to rewrite a new core from the ground up.

(c) While this feature is a clever thing that helps us address important requirements, but there are workarounds, even if they're not ideal and require a few extra configuration steps and not simply COLLECT(). So you could argue that it's for the greater good that we don't get this until after higher-priority features roll out.

All just speculation, but I feel for dev teams, and want to assume positive intent on the part of Anaplan. Hopefully this helps at least one person out there be less frustrated. 😅

david.savarin

While i am in no way aware of anaplan internal working from a tech architecture point of view, allowing liss to be added without restrictions of format, just for the purpose of having them in a list for mapping and such, does not seem to be so structuring this compared to the number of upvotes on this.

tomgilbert

I agree, it would be really helpful to enable mapping/filtering of non-number formatted line items.

CommunityMember120831

Upvoting this in 2024.

It's been years since Anaplan introduced any new modeling features beyond just a refreshed interface (the new module experience).

Anaplan product team is more interested in milking their existing customers with pay features (workflow, data orchestrator, etc) than giving their model builders more options these days.

AmalGHL

An update from Anaplan would be appreciated.

Misbah

If it has been sitting here for years that it means it is not going to be delivered. I mean, even garnering 200 plus votes it has been ghosted.

For Anaplan team: I understand not all of the ideas can be picked up by the product team but this one has got much attention from the model builders - it needs to be reviewed again. At least update the community on the status. Honesty will be much appreciated - even there is a comment like "Not feasible due to underlying architecture" is way better than no comment. @EricS @becky.leung