RMFInsider

Bulk processing in eMASS is how you push test results, control implementation content, POA&M items, and asset lists in at volume instead of clicking through one control at a time, and the workflow never changes: export the current template out of your own eMASS instance, fill only the columns it hands you, import it back, then clear the errors it reports row by row. eMASS accepts only templates it generated. A spreadsheet you built from a blog post, or a colleague’s copy from a different eMASS version, bounces before a single row lands. Treat every column list you read online as orientation rather than as truth for your instance.

Where bulk processing actually lives

There are two related features and people mix them up constantly. On the Controls listing view, under Control Actions, you get Import/Export, which moves data in and out through generated Excel templates. Next to it you get Bulk Processing, which applies a workflow action to a set of controls you selected on screen, with no spreadsheet involved at all.

Bulk Processing is the faster one when you have nothing to type. Check Select Visible to grab the controls on the page, then pick the action: Add Test Results, Set as Not Applicable, Submit for Review, Validate, or Skip Validation, depending on your role and where the package sits in its workflow. That is how you move forty controls to review status in ten seconds. It is not how you get narrative content in, because it does not carry text.

Import/Export is the one with the templates. Control Actions, Import/Export, then Custom Export to generate a file scoped to the controls you checkmarked, and the same screen to upload the completed file back. Menu labels and tab layouts shift between eMASS versions and between instances, so if your screen does not read exactly like this, trust your screen.

What supports import, and what does not

The object families that move through templates in the instances I have worked:

• Test results. Assessment procedures and CCIs with their latest results. The workhorse import, and the one worth learning first.
• Control implementation content. Implementation Plan fields and SLCM Strategy fields, plus Risk Assessment fields for controls that are non-compliant. You choose which of those sections to apply at upload time.
• POA&M items. Export the current POA&M, edit or add rows, import back. The fastest way to update scheduled completion dates across thirty findings.
• Hardware and software or asset lists. The system inventory, where the whole point is bulk because nobody is typing four hundred assets by hand.

What does not move through a template: artifacts. File uploads are their own workflow, so if you are mapping evidence to controls you do that in the artifact screens, not in a spreadsheet. If that part is new, start with uploading artifacts in eMASS and come back. Approval actions also stay out of the templates, which is deliberate. You cannot bulk import a decision.

Export first, every time, no exceptions

Only eMASS generated templates import successfully, and the reason is identifiers. The template carries the column headers the parser expects plus internal identifiers tying each row to a specific control, assessment procedure, CCI, POA&M item, or asset in your system. Retype the header row, reorder the columns, delete a column you thought was empty, or paste rows in from a file exported somewhere else, and the parser either rejects the file outright or, worse, matches rows to the wrong objects.

So the first step of every bulk job is an export you do not strictly need. Export the current state, open it, and look at what eMASS itself put in the cells. That tells you the date format, the exact picklist spellings, and which columns are editable. In the template I am used to, the fields you are meant to complete are highlighted and everything unhighlighted exists for matching. Fill the highlighted cells, leave the rest alone.

Keep the untouched export as a reference copy. When an import fails and you cannot tell what you changed, a diff against the clean original finds it in about two minutes.

A test results import, step by step

This is the sequence for pushing a self-assessment in from a spreadsheet, which is what you want after an internal review that produced results for a hundred and forty assessment procedures. If the underlying model is still fuzzy, the post on eMASS test results, CCIs, and assessment procedures covers the structure the template flattens.

• Open the Controls listing view for the system and filter to the controls you are updating.
• Checkmark those controls. Exclude anything inherited or owned by another provider, because results you push for controls you do not own create cleanup work for somebody else.
• Under Control Actions choose Import/Export, then Custom Export, then export the selected controls.
• Open the generated workbook and complete the highlighted cells. For test results that is Status, Test Date, Tested By, and the test results narrative at minimum.
• Use the exact status spellings the export already contains. Compliant, Non-Compliant, and Not Applicable are values, not descriptions, and N/A is not one of them.
• Save as .xlsx with no added worksheets, no merged cells, no filters left applied, and no rows inserted above the header.
• Return to the Import/Export screen, browse to the file, and upload it.
• Read the results screen before importing anything. Rows come back color coded: ready to import, errors present, and unable to import. Fix or delete the problem rows there.
• Commit the import, then confirm it. Two clicks, and the second one is the one that writes.
• Spot check five controls in the interface and confirm the date, the status, and the narrative landed where you expected.

That last step is not optional for me. Bulk imports fail quietly in one specific way: the file succeeds and the narrative lands in a field you did not intend, usually because two columns have similar names and you filled the wrong one. Five spot checks catches it before your ISSM does.

The field-level details that bounce the file

Nearly every rejection I have worked traced back to this list:

• Control acronym format. AC-2, AC-2.1, and AC-2(1) are not interchangeable across eMASS versions. Whatever the export wrote in that column is the format the import expects.
• CCI identifiers. Full form with leading zeros, such as CCI-000018. Excel will reformat a CCI column if you retype it, and a stripped zero breaks the match.
• Date format. Copy the format already in the exported cells, and format the column as text if Excel keeps helping. Regional formats are the classic failure: a date read as day-month instead of month-day gets rejected or, worse, silently accepted as a different day.
• Picklist values. Status, compliance, and severity fields validate against exact strings. A trailing space counts. A lowercase letter counts. Copy the value from an existing row rather than typing it.
• Character limits. Narrative fields are capped, and a pasted implementation statement that runs past the limit fails the row instead of truncating. Draft long narratives in the interface where the counter is visible.
• Blank versus deleted. These are different. A blank cell in a required column is an error. A deleted column changes the header row, which can fail the whole file. If you have nothing for a field, leave the cell empty and leave the column in place.
• Autocorrect artifacts. Curly quotes, a double hyphen converted to a dash character, and autocompleted text all reach cells and all can trip validation. Turn autocorrect off in the workbook you use for eMASS work.
• Wrong file type. Saving as .xls or .csv strips what the parser needs. Keep it .xlsx.
• Stale template. A template exported before a control set update or an eMASS version change can fail on headers alone. If a file that worked last quarter fails now, re-export before you debug anything else.

Working the rejection report row by row

The results screen is a worklist, not a verdict. Read it top down and sort the errors into three buckets: header and format problems that affect the whole file, value problems that affect specific cells, and matching problems where a row points at something that does not exist in your system.

Header or format problems mean stop. Do not patch cells. Re-export a fresh template, move your content into it, and upload again. Value problems are usually editable in place on the results screen, and for five of them that is faster than another round trip. Matching problems usually mean somebody is working from an old export, or the control left the baseline after a tailoring change, in which case delete the row and handle that control on its own.

Do not import a partially good file and plan to clean up later. Delete the bad rows, import the clean set, then run the remainder as a second batch. Two clean imports beat one messy one, because eMASS records what you wrote and an assessor reading test dates cannot see your intentions.

Permissions and package state

Bulk import is not a superpower, it is the write access you already have applied faster. If you cannot edit a control’s test results in the interface, you cannot import them either, and the file will come back with permission errors on exactly those rows.

Two things to check before you blame the file. First, your role on that system: a read-only role can export all day and import nothing, and some Bulk Processing actions belong to validator roles rather than to the ISSO. Second, the workflow state of the package. A package sitting in a review or approval step can be locked against edits, which means a file that would have imported cleanly on Tuesday fails on Thursday. If every row fails with the same permission message, stop editing the spreadsheet and ask your ISSM where the package sits in the workflow.

When bulk import is the wrong tool

Under about fifteen rows the interface is faster than the round trip, and it validates as you type. Bulk import earns its overhead at volume: a full self-assessment, a POA&M refresh moving dates across thirty findings, or an inventory load. It is also the right tool for a hardware and software list refresh, because an inventory load is exactly the volume this feature exists for.

It is the wrong tool for anything needing judgment per row. Writing a new POA&M item is a thinking task, and a spreadsheet encourages copy-paste weaknesses and identical mitigations across findings, which is exactly what gets a POA&M kicked back. Build new findings the deliberate way described in entering a POA&M in eMASS, then use bulk import for what it is good at: updating what already exists.

Before your next bulk job, do the boring thing: export, save a pristine copy, and compare your file against it whenever something fails. If you want the POA&M side of this to stay clean between imports, my POA&M Tracker is built around the same columns eMASS exports, which turns the round trip into a paste instead of a project.