Skip to main content

Filterer FAQ

What kind of problem is Filterer best for?​

Filterer is best when the primary task is to keep, remove, or isolate Records based on clear business Rules.

If the main question is "which Records belong in the output?", Filterer is usually a strong fit.

What is the difference between filtering and cleaning?​

Filtering decides which Records stay in scope.

Cleaning fixes how values are formatted or standardized.

If your source values are too inconsistent to filter reliably, clean them first and then apply Filterer.

Does Filterer change values?​

No. Filterer decides which Records are included in the output. It does not standardize, replace, mask, validate, or otherwise change Field values.

Does Filterer remove or reorder Fields?​

Filterer screens do not provide a Field keep/drop/reorder step. Filterer preserves the input Fields in the output and focuses on Record selection.

Use a mapping or restructuring Tool first if the output Field layout needs to change.

Should I start with a small sample File?​

Yes. A small, representative sample is usually a practical way to confirm that the Rules behave as intended.

Your sample should include Records that should be kept, Records that should be removed, and realistic edge cases such as blanks or boundary dates.

How narrow should a Filterer Configuration be?​

Narrower is usually better.

A Configuration should solve one clear problem well. If one setup tries to support several unrelated outcomes, it becomes harder to test and easier to misuse.

Can I reuse the same Configuration later?​

Yes. That is one of the main benefits of saving a Configuration.

A well-named, well-tested Configuration helps make recurring work more consistent across time and across team members.

How should I name a Configuration?​

Name it by business purpose, not by Tool or date alone.

Good examples:

  • Open Cases for Weekly Review
  • Exclude Test Records Before Customer Export
  • Current Month Transactions for Finance

What should I review after a Run?​

Review representative kept Records, representative removed Records, and any boundary cases that matter to the workflow.

Also check whether Rows output, Rows removed, and Problems make business sense.

What if the output looks too large or too small?​

Treat that as a signal to investigate before sharing the result downstream.

Common causes include using the wrong input version, selecting the wrong Configuration, setting the wrong default behavior, ordering Rules incorrectly, or relying on source Fields that contain unexpected values.

What should I do if one Record behaved unexpectedly?​

Start with that specific Record.

Check the source values in the Fields used by the Configuration, confirm that the correct Configuration was selected, review the default behavior, and test again on a small sample that includes the Record.

Should I build one "master" Configuration for everything?​

Usually no.

Most teams get better results from several focused Configurations than from one large Configuration trying to handle every possible scenario.

How do I handle blanks or unusual values?​

Plan for them explicitly.

During testing, include Records with blanks, unexpected categories, unusual dates, or other real-world variations that might affect the Rule outcome.

What if the business Rule changes later?​

Update the Configuration intentionally and retest it on representative data.

Do not assume that a previously correct setup still matches the new Rule without validation.

When should I use another Tool first?​

Use another Tool first when the source data must be cleaned, deduplicated, validated, mapped, or reshaped before the Record-selection logic is ready to review.

Is Filterer only for removing Records?​

No. Filterer can be used to:

  • keep a desired subset
  • remove unwanted Records
  • isolate a population for review, export, or a downstream step

The common thread is that the main task is deciding which Records belong.

What is the best way to make Configurations easier for teammates to understand?​

Use clear names, keep the purpose narrow, document the business intent briefly, and avoid unnecessary complexity in the Rule design.

What if I am not sure Filterer is the right Tool?​

Return to the question: "Am I trying to choose which Records belong, or am I trying to fix, validate, map, or reshape the data first?"

If the main task is Record selection, Filterer is likely the right place to start.