1Z0-1090-24 Cheat Sheet
Cheat sheet: implementation reference for Oracle 1Z0-1090-24: Work and Asset Cloud objects, work flows, assets, inventory, security, integrations, and exam traps.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
This page is independent exam-prep support for the Oracle Utilities Work and Asset Cloud 2024 Implementation Professional (1Z0-1090-24) exam. Use it to review implementation concepts, object relationships, process choices, and common scenario traps for Oracle Utilities Work and Asset Cloud.
Focus on how implementation objects work together: assets drive work, work consumes labor/materials, work produces costs, preventive maintenance generates future work, and integration/security/configuration controls the process.
The exam is implementation-focused. Expect questions that test whether you can recognize the right configuration object, lifecycle step, implementation decision, or troubleshooting approach—not just recall product labels.
This page is IT Mastery exam-prep support. It is not affiliated with Oracle and does not replace Oracle documentation, training, or the official exam guide.
Implementation Mental Model
Oracle Utilities Work and Asset Cloud implementation questions usually test whether you can place a requirement in the correct layer.
| Layer | What Belongs Here | Typical Implementation Decisions | Common Trap |
|---|---|---|---|
| Foundation | Organizations, locations, calendars, reference values, users, roles | Define structure before loading assets or open work | Trying to configure transactions before dependencies exist |
| Asset management | Asset hierarchy, asset locations, specifications, attributes, conditions | Decide how assets are identified, installed, tracked, inspected, and retired | Confusing a physical asset with the place where it is installed |
| Work management | Work requests, work orders, activities, tasks, job plans, permits, crews | Define planning, approval, scheduling, execution, completion, and closure | Treating the work order as the only executable unit |
| Maintenance strategy | Preventive, corrective, condition-based, and meter-based work | Choose generation triggers and templates | Creating one-off corrective work when a repeatable PM rule is needed |
| Materials/procurement | Item catalog, stock items, storerooms, requisitions, POs, receipts, issues | Decide stocked vs non-stocked, reorder, reservation, and purchasing flows | Confusing catalog item definition with inventory balance |
| Costing/financial integration | Estimates, actuals, labor, materials, equipment, capital/expense coding | Determine cost collection and downstream accounting | Closing work before required cost validation is complete |
| Security and configuration | Oracle cloud identity, application roles, business objects, algorithms, To Do | Enforce least privilege and status-driven behavior | Assuming authentication alone grants application functions |
| Integration and migration | GIS, ERP, HR, mobile, document, analytics, conversion loads | Choose batch, web service, event, or file-based integration | Using configuration migration for transactional conversion data |
Notes and examples
Core implementation model
A useful mental model is:
Foundation configuration
- Administrative options
- Lookup values
- organization structure
- security model
- business object behavior
- batch and integration controls
Master data
- assets
- locations
- crews
- labor resources
- materials
- storerooms
- vendors
- specifications
- compatible units or standard job content where used
Transactional process
- work requests
- work orders
- activities
- material reservations
- scheduling
- execution
- completion
- costing
- closeout
Operational controls
- approvals
- exception handling
- To Do processing
- integration monitoring
- reporting
- audit and reconciliation
Optimization
- preventive maintenance tuning
- crew utilization
- material planning
- backlog management
- cost analysis
- lifecycle analytics
Core Work Flow
flowchart LR
A[Work need identified] --> B{Request or direct work?}
B -->|Triage needed| C[Work Request]
B -->|Known scope| D[Work Order]
C -->|Approved / converted| D
D --> E[Plan activities, tasks, labor, materials, permits]
E --> F[Estimate and approve]
F --> G[Schedule / assign resources]
G --> H[Execute work]
H --> I[Record labor, materials, measurements, notes]
I --> J{Complete?}
J -->|No| K[Exception / To Do / follow-up]
K --> E
J -->|Yes| L[Complete activity/order]
L --> M[Close and finalize costs]
High-Yield Object Distinctions
| Distinction | Know This for the Exam |
|---|---|
| Asset vs asset location | An asset is the maintained physical or logical item. An asset location is where an asset is installed or tracked. Assets can move; locations usually represent the operating position or place. |
| Asset specification vs asset instance | Specification/classification defines common attributes and behavior. The asset instance represents the actual maintained item. |
| Work request vs work order | A work request captures a need, issue, or request for review. A work order authorizes and groups planned/executed work. |
| Work order vs activity | Work order is the container for scope, cost, and coordination. Activity is commonly the schedulable/executable unit with labor, material, and completion details. |
| Activity vs task | Activity is work to be performed. Tasks are instructions, checklist steps, inspections, or detailed procedure items within the activity. |
| Job plan vs work order | Job plan is reusable planning content. Work order is the actual transaction created for a specific asset/location/time. |
| Preventive maintenance vs corrective work | PM is generated from a defined maintenance rule or trigger. Corrective work responds to a failure, issue, or condition. |
| Compatible unit vs job plan | Compatible units are reusable construction/design estimating units, often bundling labor/material/equipment standards. Job plans are reusable maintenance execution plans. |
| Estimate vs actual | Estimate supports planning, approval, and budgeting. Actuals are recorded labor, material, equipment, and other costs incurred. |
| Catalog item vs stock item | Catalog item identifies what can be procured/used. Stock item ties the item to inventory control at a storeroom with balances and replenishment. |
| Requisition vs purchase order | Requisition requests purchasing action. Purchase order is the purchasing commitment to the supplier. |
| Receipt vs issue | Receipt increases received/available inventory or confirms delivered non-stock goods. Issue consumes inventory to work. |
| Business object vs maintenance object | In Oracle Utilities Application Framework concepts, the maintenance object represents persisted application data structure; the business object defines lifecycle, rules, options, and behavior around that data. |
| Algorithm vs script/process | Algorithms are plugged into defined spots/events for business logic. Scripts/process flows guide user or system interaction. |
| To Do vs error log | To Do is actionable exception work for users or groups. Logs record diagnostic details. |
| Configuration migration vs data conversion | Configuration migration moves setup/configuration. Data conversion loads business/master/transaction data such as assets, balances, and open work. |
Implementation Sequence Checklist
| Phase | Key Activities | Exam Focus |
|---|---|---|
| Discover / fit-gap | Confirm work processes, asset classes, inventory model, integrations, security, reporting | Map business requirement to delivered configuration first |
| Foundation setup | Organizations, calendars, crews, cost structures, reference data, storerooms | Dependencies must exist before transactional setup |
| Asset design | Asset hierarchy, locations, specifications, attributes, conditions, warranties, documents | Decide what is an asset, what is a location, and what is an attribute |
| Work process design | Work types, statuses, activity types, job plans, approvals, permits, close rules | Status lifecycle drives behavior and validation |
| PM design | PM templates, triggers, forecast/generation rules, eligible assets/locations | Calendar, meter, and condition triggers solve different problems |
| Supply chain design | Items, stock/non-stock, storerooms, reorder, purchasing, receiving, issue/return | Material availability and costing depend on correct setup |
| Security design | Identity, roles, application services, data access, approval authority | Separate login access from functional and data permissions |
| Integration design | ERP, GIS, HR, mobile, analytics, document management, external IDs | Define system of record and error handling |
| Conversion | Load foundational data, assets, inventory balances, open work, PM rules | Parent/child order and reconciliation are critical |
| Testing | Unit, SIT, role/security, conversion, integration, UAT, cutover rehearsal | Test end-to-end flows, not only isolated screens |
Asset Management Reference
Asset Object Model
| Object / Concept | Purpose | Key Links | Implementation Notes |
|---|---|---|---|
| Asset | Maintained item or equipment | Asset location, parent asset, specification, work history, PM rules | Use for items requiring lifecycle, maintenance history, cost tracking, or regulatory/operational visibility |
| Asset location | Place or functional position where assets are installed | Asset, GIS/location data, work order, hierarchy | Use when maintenance is tied to a fixed operating position even if the asset changes |
| Asset hierarchy | Parent/child structure | Components, assemblies, systems | Enables roll-up history, navigation, and impact analysis |
| Specification / class | Standardizes asset attributes | Asset type, characteristic values, maintenance rules | Avoid custom fields when characteristics/classification can meet the requirement |
| Component | Sub-part of an asset or assembly | Parent asset, replacement work | Track separately when replacement/history matters |
| Condition / inspection | Captures condition rating, observation, or inspection result | Work activity, PM trigger, follow-up work | Can drive condition-based maintenance or corrective work |
| Measurement / meter reading | Usage or measured value | Asset, PM trigger, trend analysis | Supports usage-based maintenance when time alone is insufficient |
| Warranty | Coverage information | Asset, supplier, work cost recovery | Important for repair/replacement decisions |
| Attachment / document | Supporting file or external reference | Asset, work, procedure | Use for manuals, photos, drawings, and evidence |
Notes and examples
Asset Decision Table
| Scenario Requirement | Prefer | Why |
|---|---|---|
| “Track maintenance history for this pump” | Asset | Maintenance history and costs belong to the maintained item |
| “Track what is installed at this substation bay” | Asset location plus installed asset | Location remains stable while equipment may change |
| “All transformers need the same rating attributes” | Specification/classification | Centralizes standard fields and validation |
| “Create work when run hours exceed threshold” | Meter/measurement-based PM | Trigger depends on usage, not calendar time |
| “Create work when inspection score is poor” | Condition-based maintenance | Trigger depends on observed condition |
| “Record replacement of a subcomponent” | Component/child asset or task, depending on tracking need | Track as asset only if independent history is valuable |
Quick decision table
| If the question says… | Think first about… |
|---|---|
| “Generate work automatically” | Preventive maintenance, schedule, batch process, eligibility |
| “User cannot perform an action” | Security, status, application service, role, required fields |
| “Work appears but is not schedulable” | planning completeness, crew availability, materials, permits |
| “Costs missing from work” | actuals, material issue, labor entry, procurement receipt, costing integration |
| “Field value should be standardized” | lookup, extendable lookup, characteristic type, specification |
| “Record behavior changes by status” | business object lifecycle, algorithms, validation |
| “External system rejected data” | integration payload, reference data, validation, error handling |
| “Inventory count is wrong” | issues, returns, transfers, receipts, adjustments, UOM |
| “Assets duplicated after conversion” | identity mapping, hierarchy, location assignment, data cleansing |
| “Configuration works in test but not production” | migration, environment differences, security, reference data |
Work Management Reference
Work Object Hierarchy
| Level | Purpose | Typical Data | Exam Trap |
|---|---|---|---|
| Work request | Intake and triage | Problem, requester, asset/location, priority, symptoms | A request may not yet authorize execution |
| Work order | Authorized work container | Work type, asset/location, priority, cost codes, status, approval | Do not put every detailed step only at header level |
| Activity | Schedulable/executable work segment | Crew/craft, planned dates, labor, material, status, completion | Activity is often where field execution is managed |
| Task/checklist | Detailed instructions or observations | Steps, inspection questions, pass/fail, readings | Tasks guide execution; they are not usually the cost container |
| Job plan | Reusable template | Standard activities, tasks, labor, materials, duration | A template is not actual work until applied/generated |
| Follow-up work | Additional work identified during execution | New request/order/activity | Use when scope changes beyond original work |
Notes and examples
Work Status and Control Points
| Control Point | What to Validate |
|---|---|
| Request approval | Is the issue valid? Is duplicate work already open? Is asset/location correct? |
| Work order creation | Correct work type, priority, cost coding, asset/location, responsible organization |
| Planning | Required labor, materials, equipment, permits, safety steps, procedures |
| Approval | Estimate, priority, capital/expense classification, authority limits |
| Scheduling | Resource availability, crew skills, outage/operational windows, material readiness |
| Dispatch/assignment | Correct crew/technician, mobile readiness, route/area alignment |
| Execution | Actual labor, material issues/returns, measurements, attachments, completion notes |
| Completion | Required tasks complete, readings captured, failure/cause/remedy codes if used |
| Close | Costs finalized, open reservations/purchases handled, integrations complete |
Work Type Selection
| Requirement | Best-Fit Work Pattern |
|---|---|
| User reports a problem that needs review | Work request to work order flow |
| Known repair with defined asset and scope | Direct corrective work order/activity |
| Recurring inspection or service | PM-generated work from a maintenance rule |
| Construction/design estimate using standard units | Compatible unit / design-driven work |
| Emergency repair | High-priority corrective work with accelerated approval/scheduling |
| Inspection finds additional defect | Follow-up work request/order linked to original work |
| Work cannot proceed until material arrives | Planned work with material reservation/procurement dependency |
| Work requires safety control or permit | Activity with permit/safety prerequisites |
Preventive Maintenance Reference
| PM Type | Trigger Basis | Use When | Watch For |
|---|---|---|---|
| Calendar-based | Time interval or date | Work must occur every period regardless of usage | Avoid over-maintenance for rarely used assets |
| Meter/usage-based | Runtime, mileage, cycles, flow, or other measurement | Wear depends on usage | Readings must be reliable and associated with correct asset |
| Condition-based | Inspection result, condition score, threshold | Work depends on observed asset health | Requires consistent inspection capture |
| Event-based | Operational status or specific event | Maintenance follows installation, failure, outage, or other event | Define the source event and eligibility carefully |
| Forecasted PM | Future expected due dates | Resource/material planning | Forecast does not equal completed work |
| PM template/job plan | Reusable activities/tasks/materials | Standardize generated work | Template changes affect future generated work, not necessarily existing work |
Notes and examples
PM Troubleshooting
| Symptom | Likely Checks |
|---|---|
| PM work not generated | PM rule active? Asset/location eligible? Trigger due? Required template valid? Generation batch/process run? Errors or To Dos? |
| PM generates duplicates | Overlapping rules? Incorrect last completion/due date? Multiple eligible assets/locations? Manual work created outside PM flow? |
| Meter PM not due as expected | Latest reading present? Correct unit/measurement? Rollover/estimate handling? Reading associated to correct asset? |
| PM created but not schedulable | Missing labor/craft, invalid activity type, unavailable crew, material/permit prerequisite, status not ready |
Preventive maintenance quick review
Preventive maintenance is high-yield because it connects asset data, schedules, measurements, work generation, and operational controls.
| PM driver | Best fit | Common trap |
|---|---|---|
| Time-based | Work every fixed calendar interval | Ignoring seasonal or blackout constraints |
| Meter-based | Work after usage threshold, runtime, mileage, cycles, or flow | Generating work without reliable measurement data |
| Condition-based | Work based on inspection, threshold, or condition result | Treating condition comments as structured triggers |
| Route-based | Multiple assets or locations inspected in a defined path | Creating separate work orders when route grouping is intended |
| Regulatory or compliance interval | Required recurring inspection or maintenance | Manually tracking due dates outside the system |
PM decision rules
- If work recurs predictably, look for PM configuration rather than manual work creation.
- If work is based on usage, the measurement source must be reliable.
- If work is compliance-sensitive, pay attention to due dates, tolerances, documentation, and closeout evidence.
- If the same checklist applies repeatedly, standardize the activity content.
- If PM generation produces too much or too little work, review frequency, lead time, asset eligibility, route grouping, and meter readings.
Compatible Units and Work Design
| Concept | Purpose | Use When | Avoid When |
|---|---|---|---|
| Compatible unit | Reusable construction/design unit with standard labor, material, equipment, and costs | Utility construction or repetitive design/estimate work | Simple one-off maintenance job |
| Design | Groups compatible units into a planned construction scope | Need estimate, approval, and construction work package | Scope is already known and does not need design estimation |
| As-built update | Records what was actually installed/removed | Design/construction changes asset records | No asset/location impact exists |
| CU estimate | Standardized estimate from compatible units | Need consistent cost and material planning | Actual field conditions are completely non-standard |
| Design approval | Governance over scope/cost | Capital work or controlled construction process | Low-risk corrective maintenance |
Exam trap: a compatible unit is not the same thing as a work order. It is reusable design/estimating content that can feed work planning and execution.
Resource, Crew, and Scheduling Reference
| Object / Concept | Purpose | Implementation Notes |
|---|---|---|
| Employee/resource | Individual who can perform work or record labor | Link to skills, organization, labor rates, and security as needed |
| Craft/skill | Type of labor capability | Used for planning requirements and matching resources |
| Crew | Group of resources assigned to work | Useful for utility field work and repeated team assignments |
| Shift/calendar | Availability pattern | Drives scheduling feasibility and capacity |
| Labor rate | Costing labor actuals/estimates | Ensure rates align with costing/financial design |
| Qualification/certification | Determines whether a person/crew can perform specific work | Important for safety, compliance, or specialized work |
| Assignment | Links scheduled work to resource/crew | Assignment does not automatically mean work is complete |
| Timesheet/labor actual | Records performed labor | Drives actual cost and close validation |
Notes and examples
Scheduling Decision Points
| Scenario Says… | Check / Choose |
|---|---|
| “Crew has capacity but cannot be assigned” | Required skill, shift, organization, security, work status, area/zone |
| “Activity scheduled but no technician sees it” | Assignment, mobile integration, user security, status, dispatch process |
| “Labor cost missing” | Labor actual entry, rate setup, cost code, financial interface status |
| “Work should wait for material” | Reservation/procurement status before scheduling |
| “Only certified workers can perform it” | Qualification/certification control on activity/resource |
Inventory and Procurement Reference
Inventory Object Flow
flowchart LR
A[Item catalog] --> B[Stock item at storeroom]
B --> C{Need material?}
C -->|Available| D[Reserve / issue to work]
C -->|Not available| E[Requisition]
E --> F[Purchase order]
F --> G[Receipt]
G --> B
D --> H[Actual material cost on work]
H --> I[Return unused material if needed]
Notes and examples
Materials and Purchasing Objects
| Object | Purpose | Key Links | Exam Trap |
|---|---|---|---|
| Item catalog | Defines item identity and attributes | Supplier, commodity, unit of measure | Does not by itself mean stock exists |
| Stock item | Item managed in a storeroom | Storeroom, reorder, balance, cost | Inventory controls are storeroom-specific |
| Storeroom | Physical/logical inventory location | Stock items, issues, receipts, counts | Security and organization may restrict access |
| Material requirement | Planned material for work | Activity/job plan, reservation, estimate | Planned material is not the same as issued material |
| Reservation | Holds or earmarks stock for work | Stock item, activity | Reservation does not consume inventory until issue |
| Issue | Consumes material to work | Activity, cost, storeroom | Drives actual cost and balance reduction |
| Return | Sends unused material back | Original work/material issue | Required for accurate inventory and work cost |
| Transfer | Moves stock between storerooms | From/to storeroom | Different from issue to work |
| Cycle count/adjustment | Reconciles inventory quantity | Stock item, storeroom | Requires controls and auditability |
| Requisition | Request to procure | Work, item, supplier, approval | Precedes PO; not a supplier commitment |
| Purchase order | Purchase commitment | Supplier, items/services, receipt | PO may be for stock or direct-to-work material |
| Receipt | Confirms goods/services received | PO, storeroom, work | Receipt may update inventory or work cost depending on flow |
Stocked vs Non-Stocked Decision Table
| Requirement | Choose | Reason |
|---|---|---|
| Frequently used material with on-hand balances | Stocked item | Manage inventory, reorder, issue/return |
| One-time specialized part | Non-stock/direct purchase | Avoid maintaining unnecessary inventory |
| Material must be available before outage | Reserve stocked material or procure in advance | Supports scheduling readiness |
| Item used by many crews/storerooms | Catalog item with stock records per storeroom | Central definition, local inventory control |
| Material cost should post to work only when consumed | Issue to activity | Planned or reserved material is not actual consumption |
Inventory, materials, and procurement
Materials questions often test process boundaries.
| Need | Likely process | Key implementation concern |
|---|---|---|
| Stocked material for planned work | Reserve, issue, return from storeroom | Item master, storeroom quantity, reorder point |
| Material not normally stocked | Direct purchase or non-stock procurement | Vendor, approval, delivery timing |
| Material shortage | Transfer, purchase, substitute, or reschedule | Avoid scheduling work without material availability |
| Unused issued material | Return to inventory or adjust work actuals | Cost and stock accuracy |
| Material consumed in field | Issue to work and capture actual usage | Accurate cost rollup |
| Replenishment | Reorder or purchasing process | Min/max, lead time, demand history |
Inventory traps
- Confusing reservation with issue. Reservation plans usage; issue records actual movement and cost.
- Confusing storeroom transfer with purchase receipt. One moves internal stock; the other receives from a supplier.
- Treating non-stock items as if they always have on-hand balances.
- Closing work without reconciling issued, returned, and consumed materials.
- Ignoring unit of measure consistency during conversion or integration.
Costing and Financial Controls
| Cost Topic | Implementation Meaning | Exam Notes |
|---|---|---|
| Planned cost | Estimate from job plans, labor, materials, equipment, compatible units | Used for approval and budget planning |
| Actual cost | Cost from labor entry, material issue, procurement receipt/service, equipment use | Used for work close and financial posting |
| Capital vs expense | Classification of cost treatment | Often driven by work type, activity, asset, project, or accounting distribution |
| Cost center/account | Financial coding for work costs | Missing or invalid coding commonly blocks posting/close |
| Labor costing | Hours multiplied by configured rate logic | Requires resource, rate, and valid cost distribution |
| Material costing | Inventory/procurement transaction cost | Depends on issue/receipt and inventory costing setup |
| External financial interface | Sends costs, commitments, or accounting data to ERP/financial system | Reconciliation and error handling are key |
| Estimate variance | Difference between planned and actual | Useful for approval, analysis, and process improvement |
Notes and examples
Common exam pattern: if a scenario asks why work cannot close or costs did not post, check status, required actuals, open material/procurement transactions, missing accounting, and interface errors before assuming a product defect.
Costing and financial integration
Work and asset systems support operational costing even when the general ledger or financial system is external.
| Cost source | Example | Exam focus |
|---|---|---|
| Labor | Technician hours | Actual labor capture and rate handling |
| Material | Stock issue or direct purchase | Inventory and procurement linkage |
| Equipment | Vehicle, tool, or special equipment usage | Planned vs actual equipment usage |
| Contractor | External service provider work | Procurement and invoice integration |
| Overhead | Burden, indirect cost, or configured allocation | Configuration and accounting rules |
| Capital work | Construction or asset improvement | Correct cost collection and assetization support |
Costing traps
- Assuming planned cost equals actual cost.
- Forgetting that material cost may be captured when inventory is issued, not when it is planned.
- Closing work before all actuals are recorded.
- Mixing capital and expense work without correct accounting classification.
- Ignoring integration reconciliation between work management, inventory, procurement, and financial systems.
Oracle Utilities Application Framework Concepts
Oracle Utilities Work and Asset Cloud implementations rely on Oracle Utilities Application Framework-style configuration concepts. Know what each configuration tool is for.
| Concept | Purpose | When to Use | Trap |
|---|---|---|---|
| Maintenance object | Represents underlying maintained data structure | Understanding core data persistence and maintenance portal behavior | Do not use it as the first choice for business-process variation |
| Business object | Defines business behavior, lifecycle, options, validation, and rules | Configure object-specific behavior and lifecycle | BO lifecycle matters for status-driven processing |
| Business service | Performs reusable server-side business function | Integration, validation, process support | Not the same as a user-facing portal |
| Service script / BPA script | Guides process steps or UI/business process interaction | Guided user processes, orchestration | Avoid scripting what a delivered lifecycle/config option already handles |
| Algorithm | Plug-in business logic at defined spots | Validation, defaulting, calculation, transition behavior | Must be placed on the correct plug-in spot/event |
| Lookup / extendable lookup | Controlled reference values | Status reasons, types, categories | Do not hard-code values in integrations when configurable values exist |
| Characteristic type | Flexible attribute/metadata capture | Asset attributes, work attributes, classifications | Use governance; too many characteristics can reduce data quality |
| Portal / zone | User interface navigation and displayed data | Role-specific work centers and pages | UI visibility still depends on security |
| To Do type / role | Exception routing and user work queues | Integration errors, approval tasks, validation exceptions | Logs do not replace actionable To Dos |
| Batch control | Defines background process behavior | PM generation, interfaces, large processing jobs | Batch definition is not the same as a completed run |
Configure, Extend, or Integrate?
| Requirement | Preferred Approach | Why |
|---|---|---|
| Add a controlled asset attribute | Characteristic/specification configuration | Avoids custom data model changes |
| Add validation at a lifecycle transition | Business object lifecycle rule/algorithm | Keeps rule aligned with status change |
| Guide user through a repeatable process | Script/process configuration | Reduces training and data-entry errors |
| Add a new external system data exchange | Integration service/API/file pattern | Keeps source-of-record boundaries clear |
| Move setup between environments | Configuration migration | Configuration is distinct from transactional data |
| Load existing assets/inventory/open work | Data conversion/migration load | Business data must be validated and reconciled |
| Show role-specific operational data | Portal/zone/security configuration | Better than giving broad access |
| Automate recurring generation or interface | Batch/background process | Appropriate for scheduled or high-volume processing |
Security and Access Control
| Layer | Controls | Candidate Must Know |
|---|---|---|
| Oracle cloud identity / IAM | Authentication, users, groups, sign-in access | Confirms who the user is |
| Application user setup | User profile, default organization, preferences | Maps person to application behavior |
| Application roles / user groups | Functional access to pages, actions, services | Controls what the user can do |
| Application services | Fine-grained secured functions | Missing service access can hide actions/buttons |
| Data access | Which organizations, storerooms, assets, or work records are visible/actionable | A user may have function access but not data access |
| Approval authority | Who can approve work, cost, purchasing, or status changes | Often tied to role, amount, organization, or work type |
| Segregation of duties | Separates requester, approver, receiver, closer, administrator as required by policy | Avoid overpowered implementation roles |
| Auditability | Captures who changed what and when | Important for work, inventory, and financial transactions |
Notes and examples
Security Troubleshooting
| Symptom | Check First |
|---|---|
| User cannot log in | Cloud identity/user provisioning |
| User can log in but cannot open function | Application role/user group/application service |
| User sees function but no records | Data access, organization/storeroom/crew assignment |
| User cannot approve | Approval role/authority, amount threshold, work status |
| User cannot issue material | Storeroom access, work status, inventory permissions |
| Button/action missing | Application service, business object status, portal/zone security |
Security and access control
Implementation questions may describe a user who can see a record but cannot perform an action, or a role that should approve work but cannot.
Review the relationship among:
- users
- user groups or roles
- application services
- access modes
- approval authority
- To Do roles
- data access restrictions if configured
- environment-specific security setup
Security traps
- Assuming menu visibility equals transaction authority.
- Giving broad administrative access to solve a narrow approval issue.
- Forgetting that batch, integration, and service accounts also need appropriate permissions.
- Testing only with an administrator account and missing end-user security gaps.
- Not separating configuration access from operational work execution access.
Integration Reference
Common Integration Domains
| Domain | Typical Direction | Key Data | Implementation Concern |
|---|---|---|---|
| GIS | GIS to/from work and assets | Asset location, map coordinates, network/location identifiers | System of record for location and asset identity |
| ERP/financials | Work and procurement to/from finance | Cost distributions, POs, receipts, actuals, projects | Reconciliation and accounting validation |
| HR/workforce | HR to WACS | Employees, labor rates, organizations, skills | Effective dates and identity mapping |
| Mobile/field | WACS to/from field users | Assignments, status, labor, materials, photos, readings | Offline/conflict handling and completion validation |
| Document management | Link or exchange documents | Manuals, drawings, photos, permits | Store documents where ownership and retention are clear |
| Analytics/reporting | WACS to reporting platform | Work history, asset history, costs, KPIs | Avoid disrupting operational processing |
| External monitoring/SCADA/IoT | External to WACS | Events, alarms, readings, condition data | Filter noisy events; avoid generating duplicate work |
| Supplier/procurement network | Procurement exchange | Supplier, PO, receipt, invoice-related data | Match purchasing status to material readiness |
Notes and examples
Integration Pattern Selection
| Pattern | Best For | Avoid When |
|---|---|---|
| Real-time service/API | Immediate validation or transaction creation | High-volume bulk loads that can run asynchronously |
| Batch/file exchange | Large recurring transfers, conversions, reconciliations | User needs immediate response |
| Outbound message/event | Notify external system of status or data change | External system requires synchronous approval before save |
| Inbound interface | External system creates/updates WACS data | Source-of-record rules are unclear |
| Manual upload/import | Controlled one-time or low-volume data maintenance | Repeatable enterprise integration is required |
| Reporting extract | Analytics and historical analysis | Operational updates back into WACS |
Integration Error Handling Checklist
| Check | Why It Matters |
|---|---|
| Source and target system of record | Prevents conflicting updates |
| Cross-reference IDs | Maps external identifiers to WACS records |
| Required fields and valid lookup values | Most interface failures are validation failures |
| Transaction status | Some updates are valid only in certain lifecycle states |
| Idempotency / duplicate detection | Prevents duplicate work, assets, or receipts |
| Error routing | To Do or exception queue must assign ownership |
| Retry behavior | Avoids manual rework for transient failures |
| Reconciliation report | Confirms both systems agree after interface runs |
Data Conversion and Migration
Typical Conversion Load Order
| Order | Data Category | Reason |
|---|---|---|
| 1 | Reference/foundation data | Required by most other records |
| 2 | Organizations, calendars, crews, users, roles | Needed for ownership, scheduling, and security |
| 3 | Item catalog, suppliers, storerooms | Needed before balances and material planning |
| 4 | Asset locations, asset specifications/classes | Needed before asset instances |
| 5 | Asset instances and hierarchies | Core maintained objects |
| 6 | Inventory balances and open procurement | Requires item/storeroom setup |
| 7 | Job plans, PM rules, maintenance templates | Requires asset/spec/work configuration |
| 8 | Open work requests, work orders, activities | Requires assets, resources, materials, statuses |
| 9 | Historical work/costs, if in scope | Usually for reporting/reference, not active processing |
| 10 | Integration cross-references | Needed before go-live interfaces |
Notes and examples
Conversion Validation
| Data Area | Reconcile |
|---|---|
| Assets | Counts by class/status/location; parent-child relationships; installed assets |
| Inventory | Item balances by storeroom; valuation totals; units of measure |
| Work | Open work counts by status/type; assignments; material reservations |
| PM | Eligible assets; next due dates; generated work forecast |
| Costs | Open commitments, actuals, accounting distributions |
| Security | User counts, roles, data access, approval authority |
| Integrations | External IDs and cross-reference completeness |
Exam trap: configuration migration tools are not a substitute for conversion design. Configuration and business data have different validation, ownership, and reconciliation requirements.
Data migration sequencing
Data conversion failures often come from loading records before prerequisites exist.
| Load sequence | Examples |
|---|---|
| Foundation/reference data | organizations, lookup values, accounting references, security references |
| Master data | assets, locations, crews, labor resources, material items, storerooms, vendors |
| Relationship data | asset hierarchy, asset-location associations, crew membership, item-storeroom balances |
| Open transactions | open work, material reservations, purchase commitments |
| Historical data | closed work, cost history, asset history, measurements |
| Reconciliation | counts, balances, sample record review, exception correction |
Migration traps
- Loading assets before valid specifications or locations exist.
- Loading inventory balances without item-storeroom setup.
- Loading open work without valid crews, activities, statuses, or accounting.
- Migrating poor legacy codes directly instead of mapping to clean controlled values.
- Treating data conversion as a one-time technical upload rather than an iterative validation process.
Batch and Background Processing
| Concept | Purpose | Exam Notes |
|---|---|---|
| Batch control | Defines a background process and parameters | Know which process should be scheduled rather than run manually |
| Batch run | Execution instance of a batch process | Review status, errors, and logs for troubleshooting |
| Threading/partitioning | Processes large volumes efficiently | Configuration depends on process design; do not assume unlimited concurrency |
| Restart/retry | Continues or reruns after failure | Understand whether transactions are idempotent |
| Batch parameters | Control date range, selection criteria, mode, or processing option | Wrong parameters can create missing or unexpected output |
| Batch logs | Diagnostic information | Logs support troubleshooting but do not assign user ownership |
| To Do/exceptions | Actionable follow-up for users | Use for business resolution of failed records |
Notes and examples
Common Batch Use Cases
| Use Case | Batch/Background Fit |
|---|---|
| Generate PM work | Scheduled generation from PM rules |
| Process integration files/messages | Recurring inbound/outbound transfer |
| Recalculate or update large datasets | Controlled background processing |
| Produce extract/reporting data | Offload heavy processing |
| Retry failed transactions | Managed exception recovery |
Reporting and Operational Monitoring
| Need | Use |
|---|---|
| Day-to-day user workload | Portals, zones, work queues, To Do lists |
| Exception management | To Do dashboards, interface error queues, batch logs |
| Maintenance KPIs | Work completion, backlog, schedule compliance, PM compliance |
| Asset reliability | Failure history, condition trends, repeated corrective work |
| Inventory control | Stockouts, turns, reorder exceptions, cycle-count variance |
| Cost control | Estimate vs actual, capital/expense, work type cost trends |
| Cutover validation | Reconciliation reports and sampled transaction testing |
Scenario-Based Decision Matrix
| If the Question Emphasizes… | Think First |
|---|---|
| “Need to standardize repeated maintenance work” | Job plan and PM template |
| “Need work based on elapsed time” | Calendar PM |
| “Need work based on operating hours” | Meter/usage PM |
| “Need work based on inspection result” | Condition-based maintenance |
| “Need estimate for construction using standard units” | Compatible units/design |
| “Need to know where equipment is installed” | Asset location and install history |
| “Need to know the maintained item’s history” | Asset record |
| “Need worker cannot see assigned work” | Assignment, status, mobile sync/integration, security |
| “Need material before scheduling” | Reservation, stock availability, procurement status |
| “Need to buy non-stock material” | Requisition/PO/direct purchase process |
| “Need to move setup between test and production” | Configuration migration |
| “Need to load legacy open work” | Data conversion |
| “Need to restrict users by storeroom” | Data access plus inventory permissions |
| “Need to validate before status change” | Business object lifecycle rule/algorithm |
| “Need to route failed interface records” | To Do/exception handling |
| “Need costs sent to finance” | Financial integration and accounting distribution |
Common Exam Traps
| Trap | Correct Thinking |
|---|---|
| Assuming every issue starts as a work order | Intake may start as a work request when triage/approval is needed |
| Treating activity as optional detail | Activities often carry planning, scheduling, execution, and completion details |
| Confusing planned material with issued material | Only issue/receipt-related transactions typically drive actual material cost |
| Assuming PM forecast equals created work | Forecast supports planning; generation creates work transactions |
| Using asset when location is the stable object | If the maintained position stays but equipment changes, model the location separately |
| Ignoring status lifecycle | Many actions are valid only in specific statuses |
| Assuming login access means application access | Cloud identity authenticates; application security authorizes actions and data |
| Choosing customization before configuration | Exams usually favor delivered configuration, BO rules, algorithms, characteristics, and process setup |
| Moving transactional data with configuration tools | Use conversion/migration design for business data |
| Closing work too early | Validate actuals, tasks, materials, procurement, and financial interfaces |
| Overlooking cross-references in integrations | External IDs are essential for reliable updates and duplicate prevention |
| Loading child records before parents | Conversion order matters for assets, hierarchy, inventory, and work |
Notes and examples
Trap 1: Confusing configuration with transaction processing
If the question asks how to change behavior for many future records, think configuration. If it asks how to correct one work order, asset, or inventory movement, think transaction correction.
Trap 2: Skipping master data prerequisites
Many implementation failures are not caused by the work order itself. They come from missing:
- asset
- location
- crew
- skill
- item
- storeroom
- vendor
- accounting
- calendar
- lookup value
- security permission
Trap 3: Treating planned values as actual values
Planned labor, planned material, and estimated cost are not the same as actual labor, issued material, and posted cost.
Trap 4: Closing work too early
Closeout should confirm operational completion, required data capture, cost accuracy, material reconciliation, and exception resolution.
Trap 5: Ignoring lifecycle status
Many actions are available only in certain statuses. If an option is unavailable, review status, required data, approvals, security, and business object lifecycle rules.
Trap 6: Over-customizing
Oracle implementation exams often reward recognition of delivered configuration, extension points, and supported processes. Avoid answers that imply unsupported code or direct database manipulation unless the question clearly describes a supported extension mechanism.
Trap 7: Testing only the happy path
Real implementations must test:
- rejected approvals
- missing materials
- unavailable crews
- invalid meter readings
- integration retries
- duplicate messages
- asset retirement
- canceled work
- partial receipts
- failed batch runs
- security restrictions
End-to-End Test Scenarios to Practice
| Scenario | Must Prove |
|---|---|
| Corrective repair from request | Request intake, approval, work creation, planning, assignment, execution, close |
| PM generation and completion | PM due logic, generated work, task completion, readings, next due calculation |
| Meter-based maintenance | Reading import/entry, threshold logic, generated work |
| Inspection follow-up | Inspection task, condition result, follow-up work creation |
| Material issue to work | Planned material, reservation, issue, actual cost, unused return |
| Non-stock procurement | Requisition, PO, receipt, work cost impact |
| Crew scheduling | Skill/craft, shift availability, assignment, labor actuals |
| Asset replacement | Remove/install asset, update hierarchy/location, capture history |
| Design/CU construction | Compatible unit estimate, approval, work execution, as-built update |
| Financial posting | Accounting distribution, actual cost, interface success, reconciliation |
| Security role | User can do only assigned functions and see only allowed data |
| Integration failure | Invalid payload creates exception/To Do and supports correction/retry |
| Cutover rehearsal | Converted assets, inventory, PM, open work, security, and interfaces reconcile |
Rapid Review Checklist
Before exam day, make sure you can answer these quickly:
- What object is the system of record for the maintained item, and what object represents its installed place?
- When should work start as a request rather than a direct work order?
- Which level is planned, scheduled, assigned, and completed: work order, activity, or task?
- Which PM trigger fits calendar, usage, condition, or event requirements?
- When do you use a job plan versus a compatible unit?
- What transaction changes inventory balance: reservation, issue, receipt, return, or transfer?
- What prevents close: open costs, incomplete tasks, missing accounting, pending materials, or interface errors?
- Which security layer controls login, functional access, data visibility, and approval authority?
- When should you use configuration migration, and when should you use conversion?
- How do To Dos, batch logs, and integration errors differ?
- What validation is needed after loading assets, inventory, PM rules, and open work?
- How do status transitions drive rules, algorithms, and available actions?
Notes and examples
Final rapid checklist
Before your next mock exam, confirm that you can explain:
- Asset vs location vs specification.
- Work order vs activity vs task.
- Planned vs actual labor, material, and cost.
- Stock vs non-stock material handling.
- Reservation vs issue vs return.
- Time-based vs meter-based vs condition-based PM.
- Crew planning vs scheduling vs dispatch.
- Business object vs maintenance object vs algorithm.
- Portal or zone change vs business rule change.
- User access issue vs lifecycle status issue.
- Batch issue vs integration issue.
- Master data problem vs transaction problem.
- Data migration sequencing.
- Supported cloud configuration vs unsupported customization.
High-yield exam mindset
For 1Z0-1090-24, think like an implementation consultant configuring an enterprise work and asset management solution for a utility. Many questions can be answered by identifying:
- The business process being supported: asset, work, inventory, crew, procurement, costing, or integration.
- The system object involved: asset, location, work order, activity, resource, crew, storeroom, material, business object, algorithm, batch control, or integration artifact.
- The lifecycle point: setup, planning, approval, scheduling, execution, completion, closure, accounting, or reporting.
- Whether the issue belongs in configuration, master data, transaction data, security, batch processing, or integration.
Implementation view at a glance
| Area | What to know | Common exam angle |
|---|---|---|
| Asset management | Assets, asset hierarchy, locations, specifications, lifecycle states, characteristics | Distinguish maintainable assets from locations and descriptive attributes |
| Work management | Work orders, activities, tasks, crews, resources, permits, completion, closeout | Identify the correct process step or record type |
| Preventive maintenance | Time-based, meter-based, condition-based, recurring work generation | Know when recurring work should be generated automatically |
| Resource planning | Labor, crews, equipment, skills, calendars, shifts, availability | Match scheduling need to the proper planning object |
| Inventory and materials | Stock items, storerooms, issues, returns, transfers, reorder logic, non-stock materials | Separate stocked material from direct-purchase or one-time needs |
| Procurement | Requisitions, purchase orders, receipts, vendor interactions | Understand when procurement begins and how it links to work |
| Costing | Labor, material, equipment, contractor, overhead, capitalization support | Know where costs originate and how they roll up |
| Configuration | Business objects, maintenance objects, algorithms, portals, zones, lookup values, options | Choose configuration over customization where possible |
| Security | Users, roles, access groups, application services, approval authority | Link job responsibility to access control |
| Integration | APIs, batch, file-based exchanges, external systems, error handling | Recognize supported integration patterns and failure points |
| Data migration | Master data sequencing, validation, conversion, reconciliation | Know what must exist before transactional data can load |
| Cloud operations | Environment management, configuration migration, testing, release discipline | Respect SaaS boundaries and supported extension methods |
Work management lifecycle
flowchart LR
A[Work need identified] --> B[Work request or work order]
B --> C[Plan activities and resources]
C --> D[Reserve materials or initiate procurement]
D --> E[Schedule crew and equipment]
E --> F[Execute field work]
F --> G[Record labor, material, asset, and completion data]
G --> H[Review exceptions and costs]
H --> I[Close work]
Notes and examples
Key decision points
| Decision | Better answer pattern | Trap answer pattern |
|---|---|---|
| Is this a simple request or controlled work? | Use the object that supports planning, approvals, resources, and cost capture | Treat every service request as a full work order immediately |
| Is planning required? | Build activities, tasks, resource requirements, materials, and dependencies | Schedule work before scope and resources are defined |
| Are materials stocked? | Use inventory reservation, issue, return, or transfer process | Use purchasing for every material need |
| Is the work recurring? | Use preventive maintenance or recurring generation logic | Manually create repeated work orders |
| Is work complete? | Capture actuals, asset updates, measurements, exceptions, and closeout data | Close work without operational or cost validation |
Asset and location fundamentals
Asset questions often test whether you understand the difference between where something is and what is being maintained.
| Concept | Use it for | Exam trap |
|---|---|---|
| Asset | Maintainable equipment or infrastructure item with lifecycle, condition, and cost relevance | Using generic location records as asset substitutes |
| Location | Physical or logical place where assets reside or work occurs | Putting asset-specific maintenance history only on a location |
| Asset hierarchy | Parent-child relationships among maintainable items | Confusing hierarchy with geographic address structure |
| Specification | Standard definition of asset type, attributes, or classification | Creating custom fields for every repeated asset attribute |
| Characteristics | Flexible descriptive data | Overusing characteristics for values that should drive process logic |
| Status/lifecycle | Installed, retired, active, inactive, or other configured states | Ignoring lifecycle state when planning work |
| Measurements/condition | Operating data used for maintenance decisions | Treating meter or condition data as free-text notes |
Notes and examples
Asset implementation rules
- Model assets at the level where maintenance history, cost, inspection, or replacement decisions matter.
- Use locations for placement and operational context.
- Use specifications and characteristics to standardize asset classification.
- Avoid excessive asset granularity if the organization will not maintain, cost, or inspect at that level.
- Confirm asset data quality before enabling preventive maintenance, warranty tracking, or cost analysis.
- When an asset changes location, preserve lifecycle history rather than creating duplicate asset identities unless the business process requires it.
Work orders, activities, and tasks
Many implementation questions depend on choosing the right work object.
| Object | Typical purpose | Watch for |
|---|---|---|
| Work order | Overall work package, business purpose, cost collection, approval, lifecycle | Do not overload one work order with unrelated jobs |
| Activity | Executable unit of work, often tied to schedule, crew, resource, or asset | Activities usually drive planning and execution detail |
| Task/checklist | Detailed step, inspection item, or procedural element | Tasks are not always the right level for scheduling |
| Work request | Intake or preliminary work need | Not always approved or planned work |
| Standard job plan | Repeatable work content | Better than rebuilding the same work plan manually |
| Compatible unit | Standardized construction or utility work component where used | Do not use for one-off tasks with no repeatability |
Notes and examples
Lifecycle terms to review
- creation
- approval
- planning
- estimation
- material reservation
- procurement initiation
- scheduling
- dispatch
- field execution
- completion
- exception review
- costing
- closeout
- cancellation
A common candidate mistake is treating the lifecycle as purely sequential. In real implementations, work may return to planning because of material shortages, rejected approvals, failed inspections, changed scope, or integration errors.
Crews, labor, equipment, and scheduling
Scheduling questions usually ask what must be known before work can be scheduled effectively.
| Scheduling input | Why it matters |
|---|---|
| Work priority | Determines urgency and backlog order |
| Required skill/craft | Matches work to qualified resources |
| Crew availability | Prevents overbooking |
| Shift/calendar | Defines when labor can be assigned |
| Equipment availability | Ensures special equipment is ready |
| Material availability | Prevents failed dispatch |
| Work location | Reduces travel and supports route efficiency |
| Permits/clearances | Prevents unsafe or unauthorized work |
| Dependencies | Avoids scheduling work before prerequisites |
Practical rules
- Planning defines what must be done.
- Scheduling defines when and by whom.
- Dispatch communicates executable assignments.
- Completion records what actually happened.
- A schedule is only as reliable as labor, material, permit, and asset data.
Configuration concepts to review
Oracle Utilities implementations commonly rely on configuration rather than unsupported modification. For exam purposes, know the difference between framework configuration, business configuration, master data, and transactional records.
| Concept | Purpose | Candidate trap |
|---|---|---|
| Business object | Defines behavior, lifecycle, schema, and rules for a business entity | Treating it as only a database table |
| Maintenance object | Underlying maintainable data structure | Confusing it with a user-facing work process |
| Algorithm | Configured business logic at defined plug-in spots | Expecting all behavior to be hard-coded |
| Business service | Reusable service operation or processing logic | Using UI-only thinking for integration or automation |
| Script/service script | Guided logic or user/process flow | Using scripts when configuration or BO rules fit better |
| Portal and zone | User interface organization and data presentation | Assuming UI changes always change business rules |
| Lookup / extendable lookup | Controlled values and codes | Hard-coding values into custom logic |
| Characteristic type | Flexible attribute capture | Using it for core process state |
| To Do type/role | Exception work management | Ignoring operational exception routing |
| Batch control | Scheduled or bulk processing | Troubleshooting only from the UI |
Notes and examples
Configuration decision rules
- Prefer delivered configuration and extension points before custom behavior.
- Put reusable validation or transition behavior close to the business object lifecycle.
- Use controlled values for process-driving data.
- Use security roles and application services for access control, not UI hiding alone.
- Use batch and integration monitoring when results appear delayed or incomplete.
- Avoid solving a master data problem with custom logic.
Batch, integration, and exception handling
Cloud implementation questions often test where to investigate when data is missing, delayed, duplicated, or rejected.
| Symptom | Review first | Likely issue type |
|---|---|---|
| Work not generated | PM schedule, batch status, eligibility criteria | Configuration or batch |
| Material quantity wrong | Inventory transaction history, UOM, storeroom | Transaction or conversion |
| External system did not receive update | Integration message, API response, outbound monitor | Integration |
| Record stuck in error | To Do entry, exception log, validation message | Data or rule failure |
| User cannot complete step | status, BO lifecycle, security, required data | Process or access |
| Costs do not reconcile | work actuals, inventory issues, procurement receipts, financial interface | Cross-system reconciliation |
Notes and examples
Integration principles
- Use supported APIs, services, files, and cloud integration patterns.
- Validate reference data before loading dependent data.
- Design idempotency and duplicate prevention where external messages can be retried.
- Capture and route errors to operational owners, not only technical logs.
- Test integrations with realistic lifecycle states, not only create-only scenarios.
- Reconcile totals across systems after conversion and after ongoing interfaces.
Cloud implementation boundaries
Because this is an Oracle cloud implementation exam, expect practical SaaS implementation thinking.
| Better approach | Risky approach |
|---|---|
| Configure through supported application tools | Direct database changes |
| Use supported integration services and APIs | Unsupported back-end access |
| Migrate configuration through controlled processes | Manual untracked environment edits |
| Test quarterly or periodic updates against key processes | Assuming updates cannot affect configuration |
| Keep extensions upgrade-conscious | Recreating delivered functionality unnecessarily |
| Document configuration decisions | Relying on consultant memory |
Mini review: what to memorize vs understand
| Memorize | Understand |
|---|---|
| Major object names and process terms | Why one object is used instead of another |
| Common lifecycle stages | What data is required at each stage |
| Basic configuration artifact names | How configuration drives behavior |
| Integration and batch vocabulary | How errors are detected and corrected |
| Asset/work/inventory distinctions | How they connect in an end-to-end process |
The exam is less likely to reward isolated memorization if you cannot apply the concept to an implementation scenario.
Practice strategy for 1Z0-1090-24
Use this Cheat Sheet immediately before IT Mastery practice. A strong practice cycle is:
Topic drill one domain at a time
- asset setup
- work lifecycle
- preventive maintenance
- materials and inventory
- crews and scheduling
- configuration
- security
- integration and data migration
Review detailed explanations
- Do not only check whether your answer was correct.
- Identify the decision rule the question was testing.
- Write down the trap: wrong object, wrong lifecycle step, wrong configuration layer, or missing prerequisite.
Retake weak-topic drills
- Focus on repeated misses.
- Group mistakes by cause, not by question number.
Use mock exams for timing
- Practice reading scenario questions carefully.
- Eliminate answers that violate lifecycle, security, or SaaS configuration principles.
Finish with mixed original practice questions
- Mixed sets force you to choose among asset, work, inventory, procurement, configuration, and integration concepts without hints.