Tacton Integration with IFS Cloud

Hello ​@SATHISH,
We came across the same requirement some time back and ran some evaluations to understand how we can make it work best in our situation.

As we’ve come to understand it, primarily there are two dominant architectural patterns that one could select. 

Option #1 - Tacton as the “Master Configurator” (from what we’ve learned this was the most common)
This way Tacton handles all configuration rules, constraints, and guided selling.

In this method, IFS would typically receives the following. 

A configured BOM (structure + quantities), Selected options/attributes and Pricing (optional since most of us like to keep pricing in IFS)

Integration uses, IFS Sales Configurator REST APIs, IFS Order/Quote APIs for pushing the final configuration into a customer order or sales quotation and IFS CTO structures are minimal or not used at all.

Option #2 - Hybrid Model (Tacton + IFS CTO)

• Tacton handles front‑end configuration.

• IFS CTO model structures (e.g., option families, characteristics, rules) still exist and must align with Tacton outputs.

• Tacton would sends, Option selections mapped to IFS characteristics and a partial or full structure that IFS validates and completes

**We chose option #1, since Tacton is far more flexible for complex configuration logic, and this avoids duplicating rules in two systems.

Re the “CTO in IFS” vs “Non‑CTO (Tacton-driven)” we chose Non CTO option since for us it we felt that this has Clean architecture as Tacton owns all rules and for us it gave faster updates. however, we were weary of the strong governance required for BOM, pricing, and creation of items. 

We did not use CTO in IFS as we felt duplication of rules would be harder to maintain. 

If i am to list down the challenges/issues that we came across following is what comes to mind. 

1. Mapping complexity - you may have to develop an extensive TDD (Technical Design Document), we got our technical team to work with Tacton partner to understand and map all the relevant APIs (trust me this took more time than we imagined - lot of trial and error involved)

2. Performance issues - some times we noticed that large configurations (hundreds of components) can cause, Slow API calls, Long quote creation times and Timeouts during BOM creation

3. Change management - When engineering updates a product, we have to make sure that Tacton rules must be updated and IFS structures must be updated

4. Pricing alignment - This is critical If pricing lives in both systems, inconsistencies could gradually ocme in. 

5. Testing effort - Make sure you deisgn a robust testing regime before taking it live we subjected ours to, Regression testing and Edge-case validation to make sure everything flows through correctly. 

Finally the lessons learned for us were the following. 
- Make sure to decide CTO vs Non CTO early (based on your scenario)
- Have functional and technical resources working on the Proof of concept paralally (checking how many product options, rules, how often they change?)
-  Decide on the BoM approach full Tacton BoM vs Hybrid

Hope this helps! 
Cheers!
Sachitha

Hi ​@desilvasachitha  Thanks for the detailed feedback, this is really helpful. It looks like we can move forward with Tacton integrated with IFS without using the IFS CTO process, which is definitely a positive from an architecture and maintenance standpoint.

If we go with Option 1 (Tacton as the master configurator), do you have any additional recommendations or guidance for our technical team? Specifically, any best practices around API integration, BOM handling, performance optimization, or governance that we should be aware of early on would be very helpful.

Appreciate your insights!

Thanks,

Sathish N

Hello ​@SATHISH

Here’s what I could remember off the top in terms of what we did and the best practices on the specific areas that you are referring to above.

API Integration

1. Make sure to Lock down your API contract early

You have to define a stable interface between Tacton and IFS before development starts. Your contract should include the following.

Structure format (full BOM vs partial BOM), Attribute/option mapping conventions, Error-handling expectations, Versioning strategy, Required vs optional fields (this is very important) and How pricing is passed (if at all -depending on how you decide to handle this)

​2. Build a “translation layer” instead of point‑to‑point mapping (this was critical for us)

Avoid hardcoding Tacton > IFS mappings inside either system instead of use a middleware or mapping layer to handle the following.

Option-to-characteristic mapping, Item code translation, Structure normalization, Defaulting logic and Validation rules

3. Make sure to Implement a robust error logging & traceability

For every configuration sent to IFS, log these data points, Tacton configuration ID, Payload sent, corresponding IFS response and any warnings or partial failures

BOM Handling & Governance

This is the area that makes or breaks long‑term maintainability.

1. As I mentioned in my answer above you need to decide early: Full BOM vs Partial BOM

If it is the full BOM from Tacton it should include, Tacton owns structure, IFS simply receives and stores, Faster updates but it requires strong governance in Tacton

If it is the Partial BOM from Tacton, IFS completes the structure, you need more alignment between systems, and it is more complex to maintain

We chose Option 1 to go full BOM to avoid rule duplication.

2. Clearly establish BOM governance roles

You will need clear ownership in the following areas

• Engineering > Master items, revisions, technical structure
• Tacton team > Configuration logic, option rules
• IFS team > Costing, pricing, supply chain structure

Why: Without governance, BOM drift happens—and it’s painful to fix.

3. IMPORTANT – we learned this the hard way :) - Use stable item codes and avoid “smart” item numbering

Tacton should not need to understand engineering logic embedded in item numbers. Since there is a good chance that Smart numbers break the moment engineering changes something.

Performance Optimization

Large configurations (200–1000+ components) can stress both systems.

1. Batch API calls where possible

Avoid sending One component per API call and One attribute per API call instead send one payload per configuration.

2. Use asynchronous processing for large BOMs so that IFS can take time to create deep structures. Use async patterns so the user doesn’t wait for, BOM creation, Cost rollups and Pricing updates

3. Make sure to Cache static data

Cache in your middleware, Item metadata, Option mappings and Price lists (if stable)

**We knew from the get-go that this way it will reduce API chatter and improves response times.

Governance & Change Management

1. Create a formal “Change Impact Checklist” Whenever engineering updates a product, check, Does Tacton need rule updates?, Do item codes change?, Do BOM structures change?, Do pricing rules change? and Do mappings need updates?

2. Version your Tacton models and IFS structures together – We used synchronized versioning where, Tacton Model vX.Y and IFS BOM Revision Z

This way you would avoid mismatches where Tacton sends options that IFS doesn’t recognize.

Hope this helps your Tacton Integration initiative. 

If you feel like my inputs have helped to answer your original query, please mark this as the ‘best answer’. 

Cheers!
Sachitha