nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Which of the conditions require the use of a numbered list

tonyv

This seems to be a tricked question, I can not figured how this is not correct

[Image Removed by Moderator]

This is the reference from Planual:

[Image removed by Moderator]

Accepted answers

JaredDolich

@tonyv

Hey, you're almost done with Level 2. Congratulations. When we use a numbered list, there are usually these reasons:

With regular lists we're limited to 60 characters. Numbered lists allow us to have any size because we can swap out the generated number with the display name.
We need to have list items that have duplicate display names
In the CLASSIC dashboard, we want the user to add their own list items. This is not the case with UX since you can use forms.

Try to phrase your certification questions so we can point you in the right direction. Please don't post the questions on the Community, as others will need to work these questions out themselves. Thanks!

You got this.

All comments

JaredDolich

@tonyv

Hey, you're almost done with Level 2. Congratulations. When we use a numbered list, there are usually these reasons:

With regular lists we're limited to 60 characters. Numbered lists allow us to have any size because we can swap out the generated number with the display name.
We need to have list items that have duplicate display names
In the CLASSIC dashboard, we want the user to add their own list items. This is not the case with UX since you can use forms.

You got this.

tonyv

Hi, what do you mean by "not the case with UX"? If the users import items, it is very likely that they have a duplicated names list?

JaredDolich

@tonyv

Great question. Forms were introduced almost a year ago so users can add list items directly from the UX page. In the past, the only way to create list items was to use an action that created a list item on a numbered list. This is no longer the case with UX but you still have to do it with Classic.

There are two terrific benefits of using forms. The first is that you can create a list item to any list, numbered or regular. The second is that at the same time you create the list item you can also add all the properties assuming you've set up a system module that only uses that list.

https://help.anaplan.com/0b886638-1e4d-4322-9f36-258a83f7e445-Forms

namdevgurme

can we get same with UX

nikkitha7

Which of the following conditions would require the use of a numbered list? Select all that apply, then click Submit.
( a ) Lists will be combined to reduce sparsity.
( b ) Items in the list have duplicate names.
( c ) Item names in the list contain more than 60 characters.
( d ) End users will import items to the list by uploading a data file.
( e ) The list will contain over 10,000 items.

Which answer is correct in this?

Quick Links

Can you help?

Unanswered questions

Near-Real-Time Anaplan → Claude MCP: Any Faster Than Bulk Export + MySQL?
We're looking to feed live or near-live Anaplan data into Claude through MCP, but our current approach — exporting CSV files via the Anaplan Bulk Export API, loading them into MySQL, and querying from there — has a significant lag (hour-long turnaround). Curious if anyone has found a faster path, whether that's through the…
Anaplan Analyst performance on large, sparse models
Has anyone tested Analyst’s response quality/speed on large, sparse models (think 10+ dimensions, millions of line items)? Wondering if there’s a practical ceiling before it starts timing out.
Anaplan ⇄ Google Sheets pivot tool — feedback welcome
We've been building a tool called aplan4sheets and we'd genuinely like input from this community — both on what we've built so far and on what we should prioritize next. The problem we set out to solve: Anaplan's Excel add-in is Windows-centric, and there's no real native way to pivot Anaplan data in Google Sheets. We…