ANAPLAN MASTER ANAPLANNER KEY
CONCEPTS AND PRACTICE QUESTIONS
◉ Define DISCO
Answer: Another acronym standing for Data, Input, System,
Calculations, and Outputs. This acronym details the general flow of
modules and their separation of concerns (i.e. Data should just land
data either from data hub or from an excel file, Inputs should just
have inputs, and calcualtions should be doing the actual math).
◉ Why do we avoid SELECT and in what instances might we want to
use SELECT?
Answer: SELECT is a form of hardcoding and is generally advised
against. For example, we would not want to use SELECT with a SUM
formula or when we need a variety of information which could
change based off of a certain variable. SELECT is best used with
binary formulas or with constants (i.e. SELECT ACTUAL VERSION or
SELECT Generic Time Period).
◉ What is a best practice for naming and using timing ranges?
Answer: Time Ranges should be kept short and follow a FYxx format
(example - FY16-FY18 or even just FY18 for a single years). Time
ranges should be used to optimize certain modules where the
default model calendar is not necessary. Note - time ranges can have
,their own aggregations different from the model calendar (I.e. FY18
can have Quarters so we could name that FY18 Q).
◉ What are some additional attributes of a time range?
Answer: Time Ranges have thier own aggregation outside of the
model calendar.
Time Ranges are static and will usually require manual maintenance.
Time Ranges can go beyond the model calendar and this sometimes
mean it will "Break" period formatted line items. As a result this
mau result in potential data loss.
Time Ranges are structural changes - meaning that each time we
want to modify a time range we will have to promote it through the
ALM cycle.
◉ When to use the model calendar vs time ranges?
Answer: Generally speaking we should use the model calendar by
default. However, it is primarily dependent on the scope of the
calculations as well as the potential space savings that will come
with time ranges.
◉ How much space does each line item format use?
Answer: Boolean: 1 byte
List/Date/Time Period: 4 bytes
, Number: 8 bytes in the Classic engine; 24 bytes in Polaris (only for
non-empty cells)
Text: 8 bytes minimum in the Classic engine (+ 2 bytes per
character); 24 bytes minimum in Polaris (+ 2 bytes per character)
No Data: 0 bytes
◉ When should write access to lists be given?
Answer: Generally speaking - never.
◉ Should different roles have their own landing dashboard?
Answer: Yes.
◉ When should users have access to modules (from a dashboard
point of view)?
Answer: Users should only have access to modules through the
dashboard and it should only be in cases when the module is
calculating an important metric an end user needs to see or if there
is an input that is necessary for that role. In general, they should not
have direct access to every module nor should they be able to see
every module in the contents tab.
CONCEPTS AND PRACTICE QUESTIONS
◉ Define DISCO
Answer: Another acronym standing for Data, Input, System,
Calculations, and Outputs. This acronym details the general flow of
modules and their separation of concerns (i.e. Data should just land
data either from data hub or from an excel file, Inputs should just
have inputs, and calcualtions should be doing the actual math).
◉ Why do we avoid SELECT and in what instances might we want to
use SELECT?
Answer: SELECT is a form of hardcoding and is generally advised
against. For example, we would not want to use SELECT with a SUM
formula or when we need a variety of information which could
change based off of a certain variable. SELECT is best used with
binary formulas or with constants (i.e. SELECT ACTUAL VERSION or
SELECT Generic Time Period).
◉ What is a best practice for naming and using timing ranges?
Answer: Time Ranges should be kept short and follow a FYxx format
(example - FY16-FY18 or even just FY18 for a single years). Time
ranges should be used to optimize certain modules where the
default model calendar is not necessary. Note - time ranges can have
,their own aggregations different from the model calendar (I.e. FY18
can have Quarters so we could name that FY18 Q).
◉ What are some additional attributes of a time range?
Answer: Time Ranges have thier own aggregation outside of the
model calendar.
Time Ranges are static and will usually require manual maintenance.
Time Ranges can go beyond the model calendar and this sometimes
mean it will "Break" period formatted line items. As a result this
mau result in potential data loss.
Time Ranges are structural changes - meaning that each time we
want to modify a time range we will have to promote it through the
ALM cycle.
◉ When to use the model calendar vs time ranges?
Answer: Generally speaking we should use the model calendar by
default. However, it is primarily dependent on the scope of the
calculations as well as the potential space savings that will come
with time ranges.
◉ How much space does each line item format use?
Answer: Boolean: 1 byte
List/Date/Time Period: 4 bytes
, Number: 8 bytes in the Classic engine; 24 bytes in Polaris (only for
non-empty cells)
Text: 8 bytes minimum in the Classic engine (+ 2 bytes per
character); 24 bytes minimum in Polaris (+ 2 bytes per character)
No Data: 0 bytes
◉ When should write access to lists be given?
Answer: Generally speaking - never.
◉ Should different roles have their own landing dashboard?
Answer: Yes.
◉ When should users have access to modules (from a dashboard
point of view)?
Answer: Users should only have access to modules through the
dashboard and it should only be in cases when the module is
calculating an important metric an end user needs to see or if there
is an input that is necessary for that role. In general, they should not
have direct access to every module nor should they be able to see
every module in the contents tab.
