The option above works but like you said there are many line items that factor into the formula. The method below is for finding duplicate text fields using the aggregate x[TEXTLIST]y Conditions that apply, the list is part of a hierarchy and a parent will be used to aggregate the text fields using: (Text.Line Item[TEXTLIST: Parent.Line Item[Lookup: Systems List Parent Line Item]) 1) The S | Systems modules line item to satisfy the L2 - L1 relationship for a Parent Lookup function. 2) Text String, or the series of text fields you wish to find duplicates of, in this case, there are two text fields separated by a delimiter "_" to separate the text string combinations. 3) This line item is Applied to the Parent of the L2 List applied to the Module. This formula uses the x[TEXTLIST]y aggregate function to aggregate all of the L2 List text fields, input in the Text String Line Item (applied to L2) to its parent L1, separating the Text Strings with commas ( Text 1a_Text 2a , Text 1a_Text 2b, Text 1a, Text 2a ) 4) Line Item uses the FIND function to find the first instance of the Text String Aggregated to the L1 Parent, by looking up the TEXTLIST AGGREGATOR using the L1 systems line item, starting at point 0 of the text field. 5) This line item is used to find the SECOND instance of a text field or a single duplicate, by making the starting point of the FIND function, the number in Line item 4, + 1 . This means that if the first instance of the string is found in line item 4 that number position + 1 will be the starting point of the second formula, and if the formula is larger than 0, then there is a duplicate. 6) This is the BOOLEAN logic that indicates if a SINGLE DUPLICATE, or "Second Instance" of a text string is found. This is not ideal for the "COUNT" of strings, as a line item will be needed to find each instance after the first duplicate, however, it is extremely powerful when creating items into a numbered lists and the names need to be unique and for unicity checks for unique code creation. The TEXTLIST function is not the fastest performing function, as it concatenates text fields which are 8 bytes of memory, and is limited to 10,000 items in a list. I would suggest only using this for hierarchies with less than 1,000 items for performance purposes. I hope this helps! Tyler
... View more
Anaplan’s UX is a great feature that can be used to condense multiple dashboards into meaningful apps and pages. I see this as a huge improvement to users' overall experience of the product. By taking an example of a simple case study, I'll explain how to use the new U.S.E.R. methodology to move from Classic to UX .
A company named XYZ Corporation sells laptops across different industries in several countries. The sales operation ecosystem of this company consists of two main teams:
Sales Operations Managers
Sales Operations Managers have the following responsibilities:
Create territory coverages for the sales representatives based on the product they would be selling for their geographies.
Maintain staffing information of sales representatives.
The Territory Manager Team validates and approves/rejects territory submissions made by the Sales Operations Managers, which flow to a downstream system.
In the Classic application, information for territory coverages is stored in a separate model while the information for staffing is maintained in yet another model. When we are making a decision to move from the Classic version to the UX, the new U.S.E.R. methodology can be extremely helpful. Let’s try to understand the U.S.E.R. methodology in detail by using the above-mentioned case study as an example.
Understand the value proposition and the needs of your users.
Identify the personas and the problem you're trying to solve for them by moving from Classic to UX.
Try to understand their frustrations and how you can address them by moving to the UX.
Identify logistic details such as the complexity of use, frequency of use, type of use (read/write) and how familiar they are with Anaplan.
Identify from where you should start your migration journey.
In our case study, we have two roles: Sales Operations Managers and Territory Managers. They share similar goals and frustrations, so they have the same persona: decision maker/manager. It might be really frustrating for users to navigate across various dashboards in two models: Territory Model and Staffing Model. If we could club the dashboards in an app for each role, it would save a lot of hassle of moving across different models. Each app would contain the relevant pages used by each role depending on the type of use and frequency of use.
In this case, the app for Sales Operations Managers would contain pages with write access to manage territory and staffing pages. The app for Territory Managers would contain pages with write access to the Territory Approval dashboard and read access to the Staffing and Territory Coverages page.
More About the UX:
Anaplan's UX: Changing the Way Companies Plan
Five Lesser Known Features of the UX
Sketch out your plans and move from mind to paper.
Before you move from Classic to UX, it is strongly recommended you map out a step-by-step journey of personas.
Move from mind to pen and paper and sketch the process flow that you would need to migrate.
Identify the most-used classic dashboards and start by choosing a simple process to migrate with relevant personas. For instance, in our case study, the simple process to migrate with relevant personas would look something like this:
Execute your plan and share your results.
We have identified the personas and processes in the first two steps. Next comes the execution part of the UX.
To start, envision what apps, pages or types of dashboards you want to use. As per best practices, use worksheets whenever you need to reviewing large, detailed data sets, or filter or run actions on large data sets. Use boards whenever you have small volumes of data and you want to use it for graphical visual reporting/KPI review or as a landing dashboard.
For our case study, we would create two apps; one for each role:
Inside the Sales Operation Manager app, we have created two pages: one for managing territory information and other for managing staffing information.
For the territory page, we have chosen the worksheet layout, as this involves running actions and working (pivot, sort, filter) large volumes of data. The page contains a main grid where all territory information can be referred to or edited. On the insights panel, we have the actions and the grid to create coverages. We can expand the creation grid to the main screen whenever coverages are to be created.
For the staffing page, since it involves dealing with a small volume of data and does not involve running any processes on data, we are using the board view. We are using hierarchy as a filter if users want to view employees by geography.
Now we come to the next persona of Territory Manager. Inside the territory manager app, we have created two pages: Approve/Reject Territory and Staffing and Coverage Overview (which is just for reference and read-only).
For the Approve/Reject Territory page, we have chosen the worksheet layout, as this involves running actions and working with large volumes of data. The page contains a main grid where all territory approvals or rejection can be made. On the insights panel, we have the ability to process approvals/rejections and the grid to review changes for each sales representative. Users can expand the grid to review changes for each sales representative to the main area whenever they need to view the information from that angle.
Additionally, we can add a notification process (a great feature for Territory Managers) if they want to send out bulk notifications to Sales Operation Managers for their geography.
For the staffing and coverages review page, since it is read-only and has a small volume of data, we are using the board view. We have used hierarchy as a filter so users can view employees or coverages by geography.
Similar to the Approve/Reject Territory page, we can have a notification action that Territory Managers can use to send out bulk notifications related to staffing information to Sales Operation Managers for their region.
Repeat the process to incorporate user feedback and new features.
This phase is all about continuous iterations.
Set up regular touch points with users and look for areas of improvements. Understand what they liked about the UX and what they see as pain points.
As per their feedback, try to migrate more processes to the UX and address the pain areas.
Keep up-to-date with releases and see how you can use new features for your process.
Sonal Tripathi is a Senior Anaplan Analyst at Adobe and has been working with Adobe since 2017. She has done B.Tech in Information Technology and has 9+ years of experience with tools like Anaplan and Hyperion. She is a Certified Master Anaplanner and is responsible for maintaining the end-to-end Anaplan implementations at Adobe.
... View more
Thanks a lot @nebisht and @JaredDolich for reading the blog and providing your feedbacks. Also, thanks @JaredDolich for letting me know about the use case of cut/paste the security details right into Anaplan from Excel. I will definitely connect with Matthew to know more about it.
... View more
You can connect to each page to only one source model at a time . However, you can create an app and have multiple pages in an app .Different pages in an app can connect to different source models.
... View more