MicroStrategy Analyst common mistakes
MicroStrategy Analyst · Understand the traps and how to avoid them.
Treating every object in the schema as a standalone attribute instead of modelling hierarchical relationships, so drill-down and roll-up questions are answered by guessing which column to pick rather than by reasoning about parent-child attribute forms.
Candidates learn the attribute editor as a list of columns and never practise building a hierarchy, so they memorise isolated facts about 'attributes' and 'forms' without a mental model of how a parent attribute and its child attribute interact in a report.
What to do instead
Practise constructing a small parent-child hierarchy (for example Region > Country > City) and predict the report output at each level before checking it. When studying, always ask 'what is the parent, what is the child, and what is the key form?' so hierarchy questions become structural rather than recall-based.
Confusing attribute forms with separate attributes, so a question about displaying a description alongside an ID is answered by creating a new attribute rather than adding a form to the existing one.
The two concepts look similar on the surface (both add a column to a report), and candidates who have only read about forms without building them default to the more familiar 'attribute' concept.
What to do instead
Build one attribute with two forms (ID as key, description as display) and observe that the report shows both while grouping on the key. Learn the rule: forms describe one entity, attributes describe different entities.
Assuming a metric's aggregation behaviour is set in the report or the dataset rather than in the metric definition, and therefore choosing the wrong default when asked how a metric rolls up.
Candidates conflate the metric's own definition (its formula and its dimensionality/aggregation settings) with the report-level or VLDB-level settings that can also affect results, so they attribute behaviour to the wrong layer.
What to do instead
For each metric you study, identify three things separately: the formula, the level (dimensionality) it is defined at, and the aggregation function. Then test what happens when you remove an attribute from the report grid, so you can see the metric's own behaviour rather than the report's.
Treating a compound or derived metric as a simple arithmetic shortcut without checking the level of each component, leading to answers that ignore how differently-grained inputs combine.
Compound metrics look like spreadsheet formulas, so candidates apply spreadsheet intuition and forget that each component metric carries its own dimensionality and aggregation rules.
What to do instead
Before answering, write down each component's level and aggregation. Then reason about what happens when the components are at different levels (for example one at day, one at month) and confirm against the definition rules rather than arithmetic intuition.
Memorising that caching exists but not being able to say which layer a given result comes from, so questions about stale data or unexpected results are answered with a generic 'clear the cache'.
Candidates learn caching as a single feature rather than as several distinct layers (for example dataset/warehouse result caches, Intelligence Server caches, and any external caching), so they cannot map a symptom to a layer.
What to do instead
Draw the request path from client to Intelligence Server to the data source, and label where each cache sits and what invalidates it. Then practise diagnosing scenarios by asking 'at which layer could this stale value have been produced?' before choosing an action.
Assuming that changing a report definition automatically refreshes cached results, and therefore predicting new numbers when the underlying cached data would still be served.
Candidates think of the cache as attached to the report rather than to the dataset/query result, so they assume any edit forces a re-query.
What to do instead
Learn the invalidation triggers explicitly: what happens on schema change, on data change, on cache flush, and on report edit. Test one scenario end to end (edit a report, observe whether the data is re-queried) so the rule is anchored to observed behaviour.
Assuming that adding a filter to a report automatically restricts what data a user is allowed to see, rather than recognising that row-level security must be enforced by the platform's access model.
Report filters and security filters look identical in a report definition, so candidates assume the visible filter is the security control and overlook the separate security filter mechanism.
What to do instead
Separate the two concepts in notes: report filters shape the analysis, security filters restrict the user. Practise describing how a security filter tied to a user attribute would change what the same report returns for two different users.
Answering access-control questions by naming a single privilege (for example 'grant them access to the object') without accounting for the interaction of privileges, object ACLs, and security filters.
Candidates study each control in isolation and never build the combined model, so they give a partial answer that would not actually grant the intended access in practice.
What to do instead
For any access scenario, walk three checks in order: does the user have the privilege, does the object's ACL allow it, and does a security filter limit the rows? Only when all three pass is access effective. Practise with a scenario where one check fails and predict the outcome.
Treating AI/ML features as a black box outside governance, so questions about which data an AI assistant can surface or who can see a generated answer are answered as if the assistant bypasses the semantic layer.
Candidates assume AI features operate directly on raw data and therefore have their own separate security model, missing that governed metrics and access controls still apply.
What to do instead
Learn the principle that AI-assisted features consume governed objects (metrics, attributes, security filters) rather than raw tables, and reason from that: if a user cannot see the metric, the assistant should not surface it. Apply the same privilege/ACL/security-filter walk to AI scenarios.
Reading a question about metric dimensionality and answering with the report's attributes rather than the metric's defined level, producing answers that are right only when the two happen to coincide.
In simple practice reports the metric level and the report grid often match, so candidates never see the distinction and generalise from a coincidence.
What to do instead
Deliberately build a report where the metric level and the report attributes differ (for example a metric defined at month shown on a day-level report) and observe the result. Make 'what level is the metric defined at?' a mandatory first step for every metric question.