Hi all,

Because there have been so many questions on these forums about how to edit these req items—with no explanation on why we cannot—I decided to write my own hard sought out method below. I will be posting this elsewhere (probably copy & paste) to make sure that these instructions appear throughout the forums. Someone’s gotta do it, eh?

I wanted to share the workaround we use at my organization which allows for editing fields like Department/Division, Position (from Onboard), and the Approval Workflow—even after a requisition has been submitted. NEOGOV documentation and support often state that these fields are locked post-submission and that you must cancel and recreate the requisition. That’s not entirely true. With the right steps, you can make updates—without having to start from scratch. Make sure to read the warnings and impacts of this method before using it. 

Tl;dr Requisition items like Dept/Div, position (from Onboard), and the Approval Workflow can be modified and updated within an existing requisition if HR Admin reverts the requisition back to a Draft stage. 

NOTE: to follow my solution you must have the security permissions of an HR ADMIN.

To find the solution you are looking for, SKIP MY RANT

WARNING, Incoming rant:

But first, please allow me the following.

I don't understand NEOED's/NEOGOV's extreme reluctance to allow these fields to be editable after submission, nor do I understand their refusal to make this information easily accessible—even though users have repeatedly requested this functionality. It’s even more frustrating that this workaround isn’t documented or supported, leaving users to stumble upon it by trial, error, or sheer desperation.

Every time a solution is sought, the typical response is either:

"tHaT's nOt hoW AnY oF tHiS wOrKs, yOu NEed TO cReaTe a NEw reQuISItIOn"

or the equally unhelpful,

"You can request this feature in our IDEAS forum,"

ignoring the hundreds of similar, unresolved requests dating back years. If you don’t believe me, go and search the forums yourself...

This isn't just inconvenient—it’s a reflection of a broader issue with how feedback and product functionality are handled. Refusing to address long-standing, widely reported pain points because something is "hard-coded" or "not how the system was designed" is not a viable strategy for long-term product improvement. Also, didn’t you guys y’know...write the code?

My point is, if your users are repeatedly asking for functional features, perhaps it’s time to innovate a bit.

SOLUTION: Making Edits to Requisitions Pre- and Post-Approval

NOTE: Before using this method, make sure to read the warnings listed after this section

What You Can Change Using This Method:

• Department / Division

• Position (from Onboard)

• Approval Workflow (can be reset and re-populated based on Job Type)

How to Revert a Requisition to Draft and Make Edits:

1. Set the Requisition to "On Hold"
   In INSIGHT:

   • Go to Class Specs > Requisitions, find the requisition, and change the Authorization Status to "On Hold."

2. Insert Yourself into the Workflow

   • Edit the requisition and add a new Approval Step with yourself (or another HR Admin) listed as the approver.

3. Deny the Requisition to Return it to Draft

   • In OHC (or wherever you handle approvals), locate the new approval task, click "Deny," and return the requisition to the originator (the first person in the workflow).

4. Make Your Edits

   • Now that the requisition is back in Draft, you can update the Department/Division, Position, and Approval Workflow as needed.

⚠ Important Warnings and Considerations

Thanks to ​@claffond for raising excellent points—these are important to keep in mind before this “Back to Drafts” method:

• Use with caution. Especially if the requisition has progressed beyond initial approval stages.This method should not be used lightly. It’s best reserved for HR Admin or lead recruiting staff who understand the downstream impact.

• Avoid if candidates are in process. If candidates have already been referred, offers made, or preboarding started, reverting to draft can lead to data inconsistencies or loss of work already completed.

• System notifications will be sent. Denying a requisition will trigger automated alerts to the originator and any listed hiring managers. Communicate with them ahead of time to avoid confusion.

• Be careful with Department/Division changes. Modifying or deleting these fields may reset other key data (Hiring Managers, Position, Approval Workflow, etc.). Re-select the Job Type field before saving to avoid Approval Workflow issues.

• Canceling a requisition entirely results in the loss of recruitment cycle history, which impacts tracking, reporting metrics, and overall recruitment data integrity.

To see these warnings in context, navigate here to see the exchange between ​@claffond and I from another forum post.

🧩 Final Thoughts

Despite its limitations, this method has worked well for my organization when applied early in the process (e.g., while the requisition is still in approvals or just cleared the final step). It may not be right for you and your organization. But, with good documentation and communication, it’s a practical alternative to cancellation.

If you’ve tried this method or have any related experiences, feel free to share. The more we document real-world use cases, the better we can help each other navigate these gaps in the system.

Best,

A NEOED User