1.05-05 Format the Display Name property as a list if possible
Format the Display Name property for Numbered lists as List Formatted, not text. This is more efficient, saves a line item, minimizes text fields and simplifies mappings. However, it not recommended to create a separate list purely for this purpose; use an existing list if possible
Comments
-
Rule 1.05-05 Format the Display Name property as a list, if possible. Format the Display Name property for Numbered lists as List Formatted, not text. This is more efficient, saves a line item, minimizes text fields and simplifies mappings
Here is how it was done in Pre Planual Era.
What is wrong with this method? It’s a text format. We should try and avoid text as much as possible. Also another line item has to be created to change the text formatted line item to make it list formatted, if need arises.
Here is how it should be done in Planual Way:
Note: It is NOT recommended to create a separate list purely for this purpose; use an existing list if possible
1 -
Hello @Misbah ,
What is wrong with this method
? It’s a text format. We should try and avoid text as much as possible. Also another line item has to be created to change the text formatted line item to make it list formatted, if need arises.As we are using Numbered list, according to rule number 1.05-04 , numbered list should contain a code. And Finditem works with code only (numbered list). So, what is the need for having list formatted display name?
Thanks in advance
0 -
Because it is text and text is bad. Let's take an Employee hierarchy rolling up to Managers as an example
E1 Managers
E2 EmployeesWhat a lot of folks do is create the Display Name for both E1 Managers and E2 Employees as text. A better way is to create a "flat" list of all employees (could be numbered with the Display Name being Text). When loading members into E1 Managers and E2 Employees, the Display Name would be list formatted to Employees Flat, thus you load the "code" to the Display Name.
This has multiple advantages:
- when an employee's name changes, it is changed in one place (Employee Flat) which is replicated through to E1 Managers/E2 Employees
- you are using less text (one list vs multiple)
- you now have a list formatted line item (Display Name) in both E1/E2 lists to get information stored in Employee Flat (like hire date, etc.), and you now don't have to do another finditem().
3 -
Thanks @rob_marshall for the detail explaination. But, what if I have to create a hierarchical list
E1 Managers, E2 Employees in a spoke/working model where I import data from Data hub which consists of flat lists. In that case, Display name can't be formatted as list because we generally don't maintain flat and hierarchical list in same model. Please correct me if I am wrong.
Thanks in advance
0 -
That is incoreect, in your spoke model it perfectly fine to have both flat and hierarchical lists. When you are importing into a numbered list and the Display Name is formatted as list, import the code of the list member(flat member) to the Display Name. Anaplan is smart enough to do the translation.3
Title
- Preface
- PLANS
- Planual Conventions
- Zen of Anaplan
- Chapter 1 - Central Library
- Time
- Versions
- Users and Roles
- Contents
- Lists
- Subsets
- Line Item Subsets
- Emojis
- Chapter 2 - Engine
- Modules
- Formulas
- Line Items
- Saved Views
- Chapter 3 - UX Principles
- Hierarchy of Information
- Smart Grouping
- Reduce Visual Load
- Progressive Disclosure
- Use Consistency and Standards
- Provide Help and Guidance
- Use The Correct Data Type
- Give Users Visibility Into Status
- Match With Real World Scenarios
- Check In With End Uses Frequently
- Chapter 4 - UX Build
- Apps
- Dashboards
- Filters
- Chapter 5 - Integration
- Actions
- Processes
- Source Models
- Imports
- Exports
- Import Data Sources
- Data Hub
- Chapter 6 - Application Lifecycle Management
- Revision Tags
- Production Lists
- Architecture
- Deployed Mode
- Managing Changes During Development
- Chapter 7 - Extensions
- Excel
- PowerPoint