Ataccama ONE Agentic ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
User Community Service Desk Downloads

Build Reusable Standardization Logic

Define transformation logic once — email normalization, phone formatting, date standardization, address cleansing — and apply it everywhere using embedded plans or transformation rules. Update in one place, and every transformation inherits the change automatically. This keeps standardization consistent across your data, speeds up building new transformations, and removes the maintenance burden of duplicating logic in many places.

Why build reusable standardization logic

Without reusable components, standardization logic spreads across your transformation plans:

  • Logic is duplicated across plans: The same standardization is copied into 10, 20, or 50 transformation plans.

  • Updates require many changes: When business rules change, dozens of plans need updating.

  • Variations emerge over time: The same standardization gets applied slightly differently in each plan, creating inconsistencies.

  • Development is slow: Building new transformations means recreating the same logic from scratch.

  • No single source of truth: Logic drifts over time, and data quality varies depending on which transformation processed the records.

When standardization logic is duplicated, maintenance becomes expensive and quality suffers.

Two approaches for reusable logic

Ataccama ONE provides two approaches for reusable transformation logic.

Embedded plans

Reusable transformation components for standalone plans, other embedded plans, and transformation catalog items. Can include multiple steps and complex logic. Results are passed to the parent plan, which handles the output destination.

Transformation rules

Standardization logic designed for transformation catalog items. Must maintain the same record count: one input, one output. Ideal for organization-wide standards applied automatically every time a TCI is accessed.

Choose the approach that fits your use case, or use both together for complete coverage.

When to use embedded plans vs transformation rules

Embedded plans Transformation rules

Primary use

Reusable logic in standalone plans

Standards applied to transformation catalog items

Can be used in

Standalone plans, other embedded plans, TCIs

Transformation catalog items only

Record count

Can change (filter, aggregate, deduplicate)

Must stay the same (1 record in = 1 record out)

Complexity

Multiple steps, complex logic

Typically simpler, focused transformations

Typical examples

Phone formatting, address standardization, data enrichment

Email normalization, code formatting, value cleansing

Example A: Phone standardization with an embedded plan

An embedded plan is a reusable transformation component you build once and reference from any standalone plan, other embedded plans, or transformation catalog items.

These phone values appear across different source systems and all need to normalize to digits only:

Source Raw value Expected output

CRM

555-123-4567

5551234567

Billing

(555) 234-5678

5552345678

Support

555.345.6789

5553456789

ERP

555 456 7890

5554567890

Step 1: Create the embedded plan

  1. Go to Data Quality > Data transformations.

  2. Select Create transformation plan > Embedded plan.

  3. Name it descriptively — Standardize Phone Number.

  4. Add a description explaining what it handles and what it doesn’t (for example, whether country code prefixes are supported).

  5. Select Create.

Step 2: Configure the logic

The Input and Output steps appear automatically but require manual configuration:

  1. Define the input attributes on the Input step.

  2. Add a Transform data step between them to apply the normalization logic.

  3. Configure the Output step — choose which attributes to include in the output.

Use AI assistance in the expression field — for example: "Remove all non-digit characters from a phone number, including dashes, parentheses, dots, and spaces." If your data includes country code prefixes (for example, +1), mention that in the prompt and verify the result with sample data.

Step 3: Validate and publish

  1. Connect the steps: Input → Transform data → Output.

  2. Select Validate plan and fix any errors.

  3. Select Publish. The embedded plan is now available for use in any transformation plan across your organization.

Step 4: Use the embedded plan in transformations

Reference this embedded plan from any standalone plan that processes phone numbers, such as customer imports, vendor data, and transaction records. Every transformation applies identical normalization.

When you add an embedded plan step to another plan’s canvas, you must configure it first before the connection ports become active. Select the embedded plan and map the input attributes.

Use the same embedded plan across all your sources:

  • Customer data processing (from CRM)

  • Vendor data imports

  • Transaction records

  • Contact list processing

Every transformation applies identical normalization — no variations between plans.

Example B: Email normalization with a transformation rule

A transformation rule applies standardization logic to transformation catalog items — automatically, every time the TCI is accessed.

These email values need to be consistently lowercase and trimmed:

Raw value Expected output

John.Doe@Example.COM

john.doe@example.com

JANE.SMITH@company.com

jane.smith@company.com

user@DOMAIN.COM

user@domain.com

Step 1: Create the transformation rule

  1. Go to Data Quality > Transformation rules.

  2. Select Create transformation.

  3. Choose Manual creation or AI-assisted creation.

  4. Name it Normalize email format and select Create.

The rule editor opens with an Input and Output step. You build the logic in between.

Step 2: Configure the logic

  1. Define the input attributes on the Input step.

  2. Add a Transform data step with the normalization logic — lowercase and trim the email field.

AI assistance is available in any expression field — for example: "Convert email to lowercase and trim leading and trailing whitespace."
Transformation rules must maintain the same record count — one record in, one record out. Do not add Filter or Group aggregator steps.

Step 3: Validate and publish

  1. Connect the steps: Input → Transform data → Output.

  2. Select Validate plan and fix any errors.

  3. Select Publish to make the rule available across your organization.

Step 4: Apply to a source catalog item

  1. Open a catalog item containing email addresses.

  2. Open the Prepare data tab.

  3. Select Add preparation set.

  4. Enter a name and select Create.

  5. Inside the preparation set, select Add transformation rule.

  6. Choose Normalize email format.

  7. Select Apply.

  8. Publish the preparation set.

  9. Select Create output to produce a transformation catalog item with the normalized data.

Repeat for any other catalog items that contain email addresses — customer tables, contact tables, support records — for consistent normalization across your organization. See Prepare Data with Transformation Rules for the full workflow.

Step 5: Update the rule

When requirements change, open the rule, update the logic, and republish. Preparation sets using this rule pick up the new logic the next time their output is generated — no need to update each one individually.

Test changes with sample data before publishing. All preparation sets using the rule are affected.

Combine embedded plans and transformation rules

For complete coverage, use both approaches together:

  • Embedded plans: For batch processing in standalone plans, such as phone normalization, address standardization, and date parsing.

  • Transformation rules: For automatic standards on catalog items, such as email normalization and code formatting.

Both approaches use the same expression patterns, so logic stays consistent across both.

Build a standardization library

Over time, build a collection of reusable components for the patterns your organization uses repeatedly.

Common standardization

  • Normalize email: Lowercase and trim whitespace.

  • Normalize phone: Digits only, handle common formats.

  • Uppercase code: Trim and uppercase status codes and country codes.

  • Normalize date: Detect format and convert to a consistent date type.

  • Standardize address: Title-case city, uppercase state, trim fields.

Data validation

  • Validate email format: Flag records where email doesn’t match the expected pattern.

  • Required field check: Flag records where a key field is null or empty.

  • Pattern match: Detect whether a value matches a known format.

Data enrichment

  • Calculate full name: Derive from first and last name fields.

  • Extract domain: Pull the domain from an email address.

  • Derive age category: Calculate from birth date.

Use consistent naming conventions to make components easy to find:

  • Embedded plans: Standardize [Field] or Enrich [Data Type]

  • Transformation rules: Normalize [Field] or Validate [Field]

Best practices for building reusable components

  • Start with what you repeat most: Identify the standardization you apply most frequently and build reusable components for those first.

  • Keep plans focused: Each component should do one thing well; build multiple small components rather than one complex one.

  • Document clearly: Describe what the logic does, when to use it, and what inputs it expects.

  • Name descriptively: Standardize Phone Number is better than Phone Logic.

  • Test thoroughly: Validate with diverse sample data before publishing, including edge cases.

  • Version carefully: When updating, test changes before publishing; all downstream plans inherit the change automatically.

  • Organize by category: Group related components: standardization, validation, enrichment.

  • Review periodically: Identify unused components and consolidation opportunities.

Next steps

Was this page useful?