Categories
0
votes
Sign in to Vote
Unified, Flexible Bulk Import with Column Mapping and Name-Based Field Values
Under review
Summary
Consolidate the platform's separate bulk utilities (Device Import, Bulk Checkout, Check-In, Status Change) into a single import workflow that supports multiple actions in one file, accepts human-readable field values instead of internal IDs, and includes a column-mapping confirmation step so imports succeed even when column headers don't exactly match system field names.
Problem
The current bulk utilities are fragmented and rigid, which turns routine tasks into multi-step workarounds:
Fragmentation. Adding a batch of new devices and assigning them requires at least two separate imports — Device Import, then Bulk Checkout — using different templates. If some devices also need a status change, that's a third pass. Each utility has its own template and its own quirks (Device Import expects Device Model, Purchase Date, Serial Number, Barcode/Asset Tag, Building SIS ID; Bulk Checkout expects Staff/Student Local ID and Serial/Barcode/Asset Tag; Check-In and Status Change use their own layouts). There's no way to do the whole workflow in one file.
Checkout targets are limited. Bulk Checkout only supports users. Assignments to rooms, carts, or (with the granular warehouse feature) specific bins can't be done in bulk, even though those are valid assignment targets elsewhere in the system.
Internal IDs required instead of names. Several fields in the current importers require an internal identifier rather than the value users actually see in the UI. Device Import expects Building SIS ID instead of the building's name. Device Model is even worse: the importer doesn't accept the model name at all — users have to open the Device Model Table, look up the model (e.g., "CR-5 Pro"), and copy its numeric Value (e.g., 356) into the file. That table currently contains hundreds of rows, and any typo, stale value, or newly added model that hasn't been communicated results in silent failures or rejected rows. Staff end up maintaining side-by-side lookup sheets just to build a valid import, which defeats the purpose of a bulk utility.
No header flexibility. If a column is labeled "Fund" but the system expects "Fund Account," the import fails. Users are expected to know the exact system field names and match them character-for-character, which doesn't scale across teams, vendors sending device lists, or files exported from other systems.
Concrete Example: Today vs. Proposed
Scenario: 200 new 3D printers arrive and need to be added to the system, assigned to specific rooms, and marked as deployed.
Today (three imports, at least two lookup tables):
Build a Device Import file. For each row, open the Device Model Table, find "CR-5 Pro," copy its Value of 356 into the Device Model column. Look up each destination building's SIS ID and enter that too. Upload and hope every row succeeds.
Build a Bulk Checkout file — but Bulk Checkout only supports users, so rooms can't be assigned in bulk at all. Each of the 200 room assignments has to be done another way.
Build a Status Change file to mark the batch as "Deployed."
Proposed (one import):
Build one file with columns like Serial Number, Model (accepts CR-5 Pro), Building (accepts Lincoln Elementary), Assign To Type (room), Assign To (accepts room name), Status (Deployed). Upload, confirm the column mapping on the preview screen, review any flagged rows, commit. Done.
Proposed Solution
One consolidated import utility that can create or update devices and perform assignment, check-in, check-out, and status changes in a single file. The action for each row is either inferred (new serial → create; existing serial with a new assignee → checkout) or set explicitly via an optional Action column (create, update, checkout, checkin, status_change), so a single file can mix actions across rows.
Checkout to any valid target, not just users. Add columns (or a combined "Assign To Type" + "Assign To" pair) supporting user, room, cart, warehouse, and — where the granular warehouse feature is in place — bin. The utility resolves the target the same way the UI does.
Human-readable values accepted everywhere. Any field that today requires an internal identifier — Device Model Value, Building SIS ID, status ID, supplier ID, category ID, etc. — should also accept the display name shown in the UI (e.g., "CR-5 Pro", "Lincoln Elementary", "Deployed"). The importer resolves the value the same way the UI does. When a name is ambiguous (two models with the same name under different brands, two buildings with the same name), the mapping/preview screen surfaces the conflict with a dropdown to pick the intended record. Internal IDs continue to work for anyone who prefers them or has automation built around them, so nothing breaks — the change is purely additive.
Column-mapping confirmation screen shown after upload and before commit:
Each detected column in the file is listed with a dropdown of system fields to map it to.
The system pre-selects the best match based on header name, with a confidence indicator.
Unmapped or ambiguous columns are flagged; required fields not yet mapped block the import until resolved.
Users can save a mapping as a named template (e.g., "Vendor X device list") so recurring imports skip this step.
Row-level validation preview on the same screen: a sample of rows showing which will succeed, which will fail, and why (unknown value, duplicate serial, missing required field), with the ability to fix inline or download an error report, correct the file, and re-upload.
Consistent, downloadable template with every supported column, marked as required/optional and with example values, replacing the current four separate templates.
Audit and rollback. Each bulk import is recorded as a single event with a summary of what was created, updated, checked in/out, or status-changed, and can be rolled back or partially reversed within a defined window.
Who Benefits
IT and asset management staff — one import instead of two or three; far less time preparing files and reconciling failures.
Deployment and rollout teams — receive a device shipment, assign to rooms/carts/users, and set status in a single pass.
Help desk and site technicians — bulk check-ins after collection events (end of school year, refresh cycles) without stitching together multiple utilities.
Data owners in other departments — can hand off a spreadsheet using their own column names and still have it import cleanly.
New admins and occasional users — mapping dropdowns and validation previews remove the "you have to know the exact field names" learning curve.
Vendors and integrators — can send device lists in their native format without reformatting to match the platform's exact schema.
References / Comparable Implementations
Salesforce Data Loader / Data Import Wizard — column mapping UI with saved mapping templates and validation preview.
HubSpot and Zendesk imports — dropdown-based header matching with fuzzy suggestions.
ServiceNow Import Sets with Transform Maps — one staging import feeding multiple target actions via mapping rules.
Snipe-IT CSV importer — a lighter ITAM-specific example of header mapping.
Google Workspace and Microsoft 365 bulk user import — precedent for accepting display names alongside internal IDs.
Consolidate the platform's separate bulk utilities (Device Import, Bulk Checkout, Check-In, Status Change) into a single import workflow that supports multiple actions in one file, accepts human-readable field values instead of internal IDs, and includes a column-mapping confirmation step so imports succeed even when column headers don't exactly match system field names.
Problem
The current bulk utilities are fragmented and rigid, which turns routine tasks into multi-step workarounds:
Fragmentation. Adding a batch of new devices and assigning them requires at least two separate imports — Device Import, then Bulk Checkout — using different templates. If some devices also need a status change, that's a third pass. Each utility has its own template and its own quirks (Device Import expects Device Model, Purchase Date, Serial Number, Barcode/Asset Tag, Building SIS ID; Bulk Checkout expects Staff/Student Local ID and Serial/Barcode/Asset Tag; Check-In and Status Change use their own layouts). There's no way to do the whole workflow in one file.
Checkout targets are limited. Bulk Checkout only supports users. Assignments to rooms, carts, or (with the granular warehouse feature) specific bins can't be done in bulk, even though those are valid assignment targets elsewhere in the system.
Internal IDs required instead of names. Several fields in the current importers require an internal identifier rather than the value users actually see in the UI. Device Import expects Building SIS ID instead of the building's name. Device Model is even worse: the importer doesn't accept the model name at all — users have to open the Device Model Table, look up the model (e.g., "CR-5 Pro"), and copy its numeric Value (e.g., 356) into the file. That table currently contains hundreds of rows, and any typo, stale value, or newly added model that hasn't been communicated results in silent failures or rejected rows. Staff end up maintaining side-by-side lookup sheets just to build a valid import, which defeats the purpose of a bulk utility.
No header flexibility. If a column is labeled "Fund" but the system expects "Fund Account," the import fails. Users are expected to know the exact system field names and match them character-for-character, which doesn't scale across teams, vendors sending device lists, or files exported from other systems.
Concrete Example: Today vs. Proposed
Scenario: 200 new 3D printers arrive and need to be added to the system, assigned to specific rooms, and marked as deployed.
Today (three imports, at least two lookup tables):
Build a Device Import file. For each row, open the Device Model Table, find "CR-5 Pro," copy its Value of 356 into the Device Model column. Look up each destination building's SIS ID and enter that too. Upload and hope every row succeeds.
Build a Bulk Checkout file — but Bulk Checkout only supports users, so rooms can't be assigned in bulk at all. Each of the 200 room assignments has to be done another way.
Build a Status Change file to mark the batch as "Deployed."
Proposed (one import):
Build one file with columns like Serial Number, Model (accepts CR-5 Pro), Building (accepts Lincoln Elementary), Assign To Type (room), Assign To (accepts room name), Status (Deployed). Upload, confirm the column mapping on the preview screen, review any flagged rows, commit. Done.
Proposed Solution
One consolidated import utility that can create or update devices and perform assignment, check-in, check-out, and status changes in a single file. The action for each row is either inferred (new serial → create; existing serial with a new assignee → checkout) or set explicitly via an optional Action column (create, update, checkout, checkin, status_change), so a single file can mix actions across rows.
Checkout to any valid target, not just users. Add columns (or a combined "Assign To Type" + "Assign To" pair) supporting user, room, cart, warehouse, and — where the granular warehouse feature is in place — bin. The utility resolves the target the same way the UI does.
Human-readable values accepted everywhere. Any field that today requires an internal identifier — Device Model Value, Building SIS ID, status ID, supplier ID, category ID, etc. — should also accept the display name shown in the UI (e.g., "CR-5 Pro", "Lincoln Elementary", "Deployed"). The importer resolves the value the same way the UI does. When a name is ambiguous (two models with the same name under different brands, two buildings with the same name), the mapping/preview screen surfaces the conflict with a dropdown to pick the intended record. Internal IDs continue to work for anyone who prefers them or has automation built around them, so nothing breaks — the change is purely additive.
Column-mapping confirmation screen shown after upload and before commit:
Each detected column in the file is listed with a dropdown of system fields to map it to.
The system pre-selects the best match based on header name, with a confidence indicator.
Unmapped or ambiguous columns are flagged; required fields not yet mapped block the import until resolved.
Users can save a mapping as a named template (e.g., "Vendor X device list") so recurring imports skip this step.
Row-level validation preview on the same screen: a sample of rows showing which will succeed, which will fail, and why (unknown value, duplicate serial, missing required field), with the ability to fix inline or download an error report, correct the file, and re-upload.
Consistent, downloadable template with every supported column, marked as required/optional and with example values, replacing the current four separate templates.
Audit and rollback. Each bulk import is recorded as a single event with a summary of what was created, updated, checked in/out, or status-changed, and can be rolled back or partially reversed within a defined window.
Who Benefits
IT and asset management staff — one import instead of two or three; far less time preparing files and reconciling failures.
Deployment and rollout teams — receive a device shipment, assign to rooms/carts/users, and set status in a single pass.
Help desk and site technicians — bulk check-ins after collection events (end of school year, refresh cycles) without stitching together multiple utilities.
Data owners in other departments — can hand off a spreadsheet using their own column names and still have it import cleanly.
New admins and occasional users — mapping dropdowns and validation previews remove the "you have to know the exact field names" learning curve.
Vendors and integrators — can send device lists in their native format without reformatting to match the platform's exact schema.
References / Comparable Implementations
Salesforce Data Loader / Data Import Wizard — column mapping UI with saved mapping templates and validation preview.
HubSpot and Zendesk imports — dropdown-based header matching with fuzzy suggestions.
ServiceNow Import Sets with Transform Maps — one staging import feeding multiple target actions via mapping rules.
Snipe-IT CSV importer — a lighter ITAM-specific example of header mapping.
Google Workspace and Microsoft 365 bulk user import — precedent for accepting display names alongside internal IDs.
Comments (0)
No comments yet
Be the first to share your thoughts on this feature request.
Add a Comment
Sign in to add a comment to this feature request.
Sign In