The mapping is where an Agile programme is won or lost. Class by class, attribute by attribute, object by object — how the Agile record is expressed in the Fusion Cloud PLM object model, and what to do with the parts that have no natural home.
Agile and Fusion Cloud PLM both manage product records, but they do not model them identically. The mapping is a design deliverable, agreed and signed before anything is built, not a set of assumptions embedded in a script.
Items map by class. Agile subclasses, including the ones added over the years, resolve to Fusion item classes and catalog assignments. Lifecycle phases map to item statuses and lifecycle phases; the two vocabularies rarely align one to one, so the crosswalk is explicit and versioned rather than inferred.
Attributes split three ways. Standard Agile attributes with a direct Fusion equivalent map straight across. Page Two and Page Three fields, which carry business-critical data under generic names in most long-lived instances, are resolved to their actual meaning first and then mapped to standard attributes or to extensible and descriptive flexfields. Anything with no sensible target is defaulted or archived, and that decision is recorded either way.
Structures, AML and changes each map onto their own Fusion interface. The item FBDI template carries the latest released revision with its attributes, flexfields, AML and attachments; the structure template carries components, substitutes and reference designators; the change order template replays completed changes to rebuild revision history and redlines.
Where Agile programmes consistently lose time, and what the design has to settle.
Subclasses accumulated over a decade may carry data the standard object model does not describe. Each needs a target class decision, not a default.
Flex fields named Text01 through Text30 holding business-critical values. The mapping cannot start until someone says what each one means.
Renumbering, padding or prefixing must apply consistently to structures, AML, changes and attachments, not just the item master.
Variant spellings consolidated to one governed record before AML is rebuilt, or the AML counts will never reconcile.
Revisions cannot carry overlapping effectivity ranges in the target, so overlaps in the source are resolved during transformation.
The same drawing on several revisions needs distinct document identity in the target, or later revisions silently overwrite earlier ones.
Evidence first, decisions second, build third.
Which classes exist, which attributes are populated, on what proportion of records and with what value distribution. Unused fields drop out of scope immediately.
The Fusion item classes, catalogs, statuses and flexfields available to map into, which depends on how the target has been configured.
Class, lifecycle, UOM and code-set translations drafted with every source value accounted for, including the ones that appear twice.
Attributes with no natural target settled in working sessions with engineering and quality, and the decision recorded per attribute.
The mapping signed and versioned. From that point changes are tracked, so cycle three runs known rules rather than adjusted ones.
The mapping document is organised by object family rather than by table, because that is how the target consumes the data and how the business reviews it.
Each family below has its own target interface, its own dependency position in the load order, and its own reconciliation check afterwards.
Only one of them survives the third rehearsal.
Fine as a design artefact, dangerous as the source of truth. The build drifts from it and nobody notices which version is live.
The rules exist only as code, so a business question about what happens to a field needs a developer to answer it.
One governed definition driving the build, readable by the business, versioned so every cycle is reproducible.
By class, then by attribute. Agile subclasses resolve to Fusion item classes and catalog assignments, with custom subclasses given an explicit target rather than a default. Lifecycle phases map to Fusion item statuses and lifecycle phases through a crosswalk, because the two vocabularies rarely align one to one. Standard attributes with a direct equivalent map straight across; the remainder go to extensible or descriptive flexfields, or are defaulted or archived by explicit decision.
They get resolved before they get mapped. Profiling reports which flex fields are populated, on which classes, at what fill rate and with what value distribution, which narrows the question considerably. Engineering and quality then say what each surviving field actually means, since names like Text07 do not. Each is then mapped to a standard Fusion attribute where one fits, to an extensible or descriptive flexfield where it does not, or explicitly archived rather than migrated.
No, and any mapping exercise that assumes so will fail in the build. Oracle documents import paths for items, revisions, manufacturer parts, AML, structures with components, substitutes and reference designators, attachments and change orders, and that set covers the core of a product record. Objects outside it, and custom classes or relationship types specific to your instance, are handled case by case, and some are better archived than forced into a target structure that does not fit them.
Structure entities map to the Fusion structure interfaces: components with quantities and effectivity, substitutes, and reference designators. Depth is not the constraint; sequencing is. Because every component is itself a revision-controlled item, components must exist at the correct revision before the parent structure referencing them can load, so the mapping carries the load-order dependency alongside the field mapping.
Through governed crosswalk tables rather than inline conditional logic. Each source value is listed, given a target value, and signed off, with unmapped values raised as exceptions rather than silently passed through or defaulted. Holding them as data means a business user can review the translation without reading code, and means the same input produces the same output in every cycle.
At sign-off, usually around week eight or nine, and freezing it is what makes the later cycles meaningful. After that point changes are tracked as versioned amendments rather than made in place, so when rehearsal three produces a different result from rehearsal two you can tell whether the cause was a data change or a rule change. Without that discipline the cycles stop being comparable and reconciliation loses its value.
We will profile your Agile configuration, draft the class, lifecycle and attribute crosswalks against your target configuration, and hand you a mapping document your engineering and quality teams can approve.