Prepare, validate and understand Maximo data before Maximo rejects it.

Review the mapped request and validate locally before using the simulator.

Assetize Data Workbench maps spreadsheet, JSON or XML fields into a request for the Maximo importfile action on an object structure. Local checks depend on what the target schema actually proves. You can inspect the URL, request body and hash before a preview or simulated execution. Runs and row results are stored for the signed-in account.

Demo environments are answered by a simulator inside the Worker; no request goes to Maximo. Live environments and customer-selected Maximo secret bindings are currently rejected, even if a Worker host allowlist or secret exists.

Sign in with a one-time email link; a licence is separate.

Request a magic link at /workbench/login. Its token is single-use. Data Workbench requires an account with an active or valid trial entitlement, manually granted by Assetize. Signing in or requesting evaluation does not start a subscription. Without a valid entitlement, private app routes and API data are blocked. Each account can see only its own environments, recipes, runs, rows, audits and batches. Viewer access is read-only. Public product pages and this guide do not expose account data.

Distinguish observation, reference, demo and UNKNOWN.

Workbench uses version-specific Maximo reference data for validation. Coverage limits are shown only when they affect a result. Internal collection, normalisation and processing methods are proprietary.

Recommendations use observed structure metadata only where available. A passing local check, simulator run or practice scenario does not establish that a real Maximo environment accepts the import.

Pick Direct Load unless you are moving data between versions.

Switch at any time from Versions (Direct load / Migration toggle). The choice is stored with the project, saved load sets, runs and exports.

Load a file into a 9.2.x environment in six steps.

1. Supply the target. New project → pick the environment → choose Direct load and the target version (defaults to the environment's reported version).
2. Supply the object structure and format. Pick e.g. MXAPIASSET. Structures without flat-file support switch the format to JSON.
3. Supply the data. Upload, paste, open a saved load set, or start blank from the schema's required fields.
4. Compare. In the Grid Editor fix red cells and the global issue strip until errors are 0.
5. Compare the request. Open Preview: URL, headers, body, hash, target-rule findings. Nothing has been sent.
6. Act. Send preview to inspect simulated results, then Execute after confirming the target. With live disabled, neither action reaches Maximo.

Assess the pair first, then load against the target.

1. Supply the pair. New project → Migration → source 7.6.1.3, target 9.2.x.
2. Compare schemas. Schema Explorer → the 7.6.1.3 vs 9.2.x tab lists removed, added and changed fields per the profile.
3. Compare readiness. Migration Readiness → choose object structures, optionally include the grid mapping → Run assessment. You get a score, blockers, warnings, review items and next actions.
4. Act. Load through the Grid Editor exactly as in Direct Load. Blockers from the target profile stop the send.

Only account-owned simulator environments can currently be created.

Settings shows the Worker live-request flag. The live adapter is not authorized for customer use and has not been tested against a real tenant; do not point the simulator at customer data.

The grid accepts CSV, JSON and XML, parsed in your browser.

CSV and pasted spreadsheet cells

First row is the header. The delimiter is detected automatically (comma, tab, semicolon, pipe), so cells copied from Excel work. Quoted values with embedded delimiters, quotes ("") and line breaks are supported. Headers and values are trimmed; blank lines are skipped.

ASSETNUM,SITEID,DESCRIPTION,STATUS
P-1001,BEDFORD,"Pump, raw water",OPERATING

JSON

Either an array of objects, or an object whose member, rdfs_member, rows or data property holds the records. For supported direct child fields in an observed ASSET or WORKORDER structure, map flat columns as CHILD.FIELD; the request builder compiles them to nested JSON under the observed relationship name. Other child fields are rejected, not silently flattened into a claimed import.

{"member":[{"assetnum":"P-1001","siteid":"BEDFORD"}]}

XML

The element whose children repeat most is treated as the record set. Each child element of a record becomes a column (namespace prefix removed, upper-cased). Attributes are ignored.

<MXAPIASSETSet>
  <ASSET><ASSETNUM>P-1001</ASSETNUM><SITEID>BEDFORD</SITEID></ASSET>
</MXAPIASSETSet>

File type is chosen by extension (.csv .txt .json .xml). Pasted text starting with [ or { is JSON, with < is XML, anything else CSV. Importing replaces the grid.

Every column maps to one target attribute, or is ignored.

Each header has a dropdown of the object structure's fields (* marks required). Auto-map matches by attribute name, title or alias ignoring case and punctuation. Choose ignore column to keep a column in the grid but out of the payload.

Column menu transforms apply to every row: trim, UPPERCASE, lowercase, find and replace, add prefix, fill empty with a value, normalise date to YYYY-MM-DD.

What the workbench checks before sending

Unobserved required/length flags, customer key duplicates, parent/location/site existence, organisation/site security and customer business rules remain UNKNOWN. The simulator cannot verify them against Maximo. A simulated BMX-like response is labelled SIMULATED, never a real IBM response.

Version rules come from editable profiles and are labelled as assumptions.

Profiles for 7.6.1.3, 9.0.x, 9.1.x and 9.2.x define which object structures exist, flat-file support, removed fields and changed limits. Examples in the demo profiles: ISRUNNING is treated as not importable on 9.x assets; 9.2.x limits SERIALNUM to 40 characters; 9.1.x/9.2.x restrict WOPRIORITY to 1-5. These are modelled for the MVP and carry a profile assumption tag, not verified IBM behaviour.

Two object structures are demo models whose names are deliberately prefixed: ASZDEMO_CLASSSTRUCT (classifications) and ASZDEMO_INSPFORM (inspection forms, JSON/XML only). Map them to your tenant's real object structures before any live use.

Building sends nothing; simulator preview and execute persist local results.

1. Build request produces a reviewable request preview without sending to Maximo.
2. Preview asks for confirmation showing host, environment mode, rows and versions.
3. Execute is disabled while the grid has errors and requires typing the host (can be turned off in Settings).

A run is stored as blocked without sending if the adapter is not allowed, confirmation is missing, target blockers exist, or structural errors remain. The format recommender chooses CSV only with proven flat support and no observed alias conflict; otherwise JSON. Child JSON requires an observed direct relationship. Hierarchical XML remains unsupported.

Sync and async

Sync returns row results at once. Async adds async=1&name=…, returns a status URL and stays running; the Live Run tab polls automatically (Settings: interval, default 2.5 s) or press Poll.

Save a dependency-ordered plan and poll account-owned chunk jobs.

In Load Plan, add each grid as a step and inspect prerequisite statuses. Relationships are lab observations; an external dependency is not proof that the customer environment contains a record. Choose batch size (1–500 rows) and parallelism (1–8). Steps follow dependency order; independent chunks within the same step can run concurrently. Large plans upload chunks through the staged batch API, then seal the plan; its ID in the URL restores progress after navigating away. Polling atomically claims queued jobs and persists queued, running, success and failed counts in D1.

Choose stop-on-failure or continue-on-error. A stopped batch can resume after failures are resolved; retry failed rows only uses the original per-run retry API, not successful rows. When delivery after a claim cannot be confirmed, the job becomes UNKNOWN/needs review and is never automatically resent. Chunk requests are synchronous; the batch advances asynchronously through polling, not Maximo's async-import status URL.

Exercise the authenticated production APIs with fictional records.

Developer Tools → Practice Lab can inspect schemas, compare version references, build requests, validate, preview, execute in the simulator, poll a run, retry failures, recommend formats and queue batch previews. Fictional scenarios remain clearly separated from customer data. Never interpret simulator results as proof of real Maximo acceptance.

Every run can be reopened, retried or cloned.

• Run History filters by status, mode and environment and searches id, object structure, hash or workflow.
• Retry failed as preview / Retry failed creates a new run containing only failed rows, linked to the parent.
• Clone as preview resends all rows as a preview.
• Open in grid loads the run's rows and mapping back into the editor with its workflow and versions.

Retry and clone inherit the original workflow (direct or migration).

The Dev Tools dock shows what would be, or was, sent.

Tabs include Overview, Request, Payload, Response, Live Run, Logs, Health, Inspector, Compatibility and Practice Lab. Inspect the masked request and simulated result without exposing credentials.

Packs install dependency-ordered load sets; installing sends nothing.

Available packs: Bedford Asset Foundation (locations then assets, migration pairs), Work Management Starter, Item Master Basics, and MAS 9.2 Reference Data (direct load, demo): classifications then inspection forms. Check readiness reports environment, version and field compatibility; Install creates one saved load set per step, which you open in the Grid Editor and run in order.

Export produces an MxLoader-style workbook without macros.

The .xlsx has three sheets: the data sheet (object structure, action AddChange, versions header and mapped rows), Mapping and Instructions. It is generated on the server and recorded; nothing goes to Maximo. It contains no VBA, so it is not a drop-in MxLoader macro workbook: paste the data into your own MxLoader file. Mapped CSV exports target-named columns.

Most failures name their cause in the run or the issue strip.

What is not proven yet.

• Live adapter untested against a real Maximo tenant; demo results come from a deterministic simulator whose messages imitate, not reproduce, Maximo.
• Version and migration profiles are assumptions, not verified IBM documentation.
• ASZDEMO_* object structures are invented demo models.
• Only observed direct ASSET/WORKORDER child relationships compile to JSON; real Maximo child import permissions are unverified. Hierarchical XML and unsupported child structures remain unavailable.
• Parallel batches run independent chunks within one dependency step. The Worker does not automatically retry unconfirmed sends; a stale claim requires manual review. Batch polling is not Maximo async-import polling.
• xlsx export has no macros. Grid is a custom editor sized for thousands, not millions, of rows.
• Account sessions and entitlement checks require manually granted access and the Cloudflare D1 migrations before use. VIEWER is read-only; self-service billing is not implemented.
• The Practice Lab templates and demo database use fictional data, not customer records.

Read next

Quick start: Direct Load · Accepted formats · Build, preview and execute