ACAW common mistakes
ACAW · Understand the traps and how to avoid them.
Building a workflow that reads a fixed file path or hardcoded sheet name instead of using a wildcard input or dynamic path, then failing when the exam scenario asks for a repeatable monthly refresh.
Candidates practice on one sample file and reach for the Input Data tool's default 'connect a file' mode because it is the first thing they see, without internalizing that wildcard and dynamic input exist for recurring feeds.
What to do instead
When a scenario implies recurring or multi-file input, deliberately choose the wildcard option (or a Dynamic Input with a path built from a field/formula) and verify field alignment across files before moving on.
Joining two datasets without first checking join-key uniqueness and data types, producing a silent row explosion or dropped matches, then reporting wrong totals.
The Join tool's output anchors (L/R/J) look reassuring, but candidates skip the manual inspection step and assume a 1:1 relationship that the data does not actually have.
What to do instead
Before the join, run a Summarize (Group By key, Count) on each side to confirm cardinality, confirm key data types match, and after the join check the left/right unmatched counts are explainable.
Using a Select tool to reorder or rename fields but forgetting to set the output type, so downstream numeric operations fail or dates sort as text.
The type column in Select is easy to overlook because the default 'unknown' silently inherits upstream types, and candidates focus only on the visible field list.
What to do instead
Treat the Select tool as the schema contract: explicitly set types for every field that feeds a formula, join, or sort, and re-check types after any upstream change.
Wiring a workflow linearly and letting a Filter tool's False output dangle, then not understanding why rows disappear or why a downstream count is short.
Candidates think of Filter as a conditional pass-through and forget it splits the stream, so the 'other' branch must be explicitly handled or intentionally discarded.
What to do instead
After every Filter, account for both outputs (union them back, summarize each, or consciously discard with a comment), and use Browse/Message tools to confirm row counts on both branches.
Hardcoding a value that the scenario says must be configurable (a threshold, date, or file name) directly into a formula instead of exposing it as a workflow constant or interface input.
It is faster to type the number into the expression, and candidates do not connect the scenario's 'parameterized' wording to the need for a constant or app control.
What to do instead
Scan the prompt for words like 'configurable', 'user-supplied', or 'reusable' and route those values through a Constant/Text Input or a Question tool, referencing the field in formulas.
Writing a multi-row or conditional formula without considering nulls and record order, so running totals or 'previous row' logic produces wrong results at boundaries.
Candidates test on clean sample data where the first row is non-null and sorted, and the Multi-Row Formula tool's group/order behavior is not exercised.
What to do instead
Explicitly sort before any multi-row logic, set the group-by field where appropriate, and add null-handling (IsNull/Coalesce) plus a test on an unsorted or null-containing subset.
Using a regex or string function that assumes a fixed delimiter or position, which breaks on records with extra commas, quotes, or missing segments.
Candidates validate against a few rows that happen to be well-formed and do not stress-test irregular records that the exam scenario deliberately includes.
What to do instead
Test parsing against the ugliest records in the data (extra delimiters, embedded quotes, blanks), prefer tokenize/regex with explicit handling, and add a validation branch that flags unparsed rows.
Building a predictive or spatial step (e.g., a model or spatial match) and reporting output without checking that the inputs met the tool's requirements (field types, nulls, coordinate system, target field).
The tools run without erroring even when inputs are marginal, so candidates trust the green run indicator instead of validating assumptions.
What to do instead
Before modeling, profile the target and predictors for nulls/outliers and class balance; before spatial work, confirm coordinate fields and units, then sanity-check a sample of output records against known cases.
Building an Analytic App or macro that works on the designer's machine but fails for the user because relative paths, interface defaults, or output locations were not parameterized.
Candidates test the app by running it interactively with their own selections and never simulate a different user, different folder, or empty optional input.
What to do instead
Parameterize all file paths via interface tools, set sensible defaults, test with the 'no selection' and 'alternate value' cases, and validate the app/macro from a clean run rather than a cached one.
Debugging a failing workflow by guessing at formulas instead of isolating the error with Browse/Message/Test tools, and leaving no error handling for bad records.
Under time pressure candidates edit the most complex tool first rather than bisecting the workflow, and they treat errors as something to suppress rather than route.
What to do instead
Bisect the workflow with Browse or Message tools at each stage to localize the failure, then add an explicit error-handling branch (Filter on IsNull/valid, Message tool, or Test tool) so bad records are surfaced, not silently dropped.