I Changed a Step's Required Skill and the Operator Pin Stayed

Clearing a required skill from a routing step clears its operator pin, but changing that skill to a different one deliberately keeps the pin, so a pinned person who does not hold the new skill stops the next scheduling run with a message naming the problem. That is documented behavior in EDGEBIC by User Solutions, not a defect, and it catches people because the mental model of "I changed the requirement, so the staffing must have been worked out again" is a reasonable one that happens to be wrong.

This post covers that specific sequence. If your pin is correct and the step still will not place, the availability gates are a different problem, covered in an operator pin left a step unscheduled. The wider symptom index is the EDGEBIC troubleshooting guide.

What You Are Seeing

You edited a routing step's required skill, changing it from one certification to another. The step already had a named operator pinned to it. On the next scheduling run, one of two things happens: the run stops straight away with a message that names the problem, or the step simply will not place, even though several qualified people are rostered and the machine has open capacity.

The confusing part is the machine. Capacity is clearly available, the skill clearly exists in your workforce, and the run still refuses.

Why It Happens

The Pin Survives a Skill Change by Design

Two rules govern a pin's lifetime, and they are deliberately different:

The first rule is obvious: a step with no skill requirement has nothing to pin against. The second is the one that surprises, and the reasoning behind it is worth understanding, because it tells you what a pin means.

A pin is a statement about a person, not about a skill. Planners set them for reasons the software cannot see: a customer who has approved one operator, a sign-off authority, the one person trusted with an expensive fixture. If a skill edit silently released the pin, the work would quietly move to whoever the load-balancer preferred, and the planner who set the pin would find out from the customer. Keeping the pin and stopping the run puts the decision back where it was made.

A Pinned Step Has No Pool

This explains why the number of qualified people does not help. When a step is pinned, the scheduler does not consider a pool of candidates and pick the best one. It considers exactly one person. If that person cannot do the work, there is no second choice to fall back on, so having two, five, or twenty other certified operators changes nothing.

How to tell: the step carries both a required skill and a named operator, and the named operator's certification list does not include that skill.

The Fix

Pick whichever of these three matches the truth, then re-run:

Clear the pin. Set the step's operator selector back to the automatic option. The scheduler then load-balances across everyone certified in the new skill, which is the right answer when the pin existed only because somebody happened to be the obvious choice under the old requirement.

Re-pin to someone who holds the new skill. Right when the reason for pinning is still real and you know who should now carry it.

Certify the pinned person in the new skill. Right only when that is genuinely true. Certifications carry expiry dates, so record the real one rather than a distant placeholder: an expired certification produces the same refusal later, with a different explanation. Setting up operators, skills, and rosters covers the certification list.

The Step That Catches People Twice

If the job is already scheduled, edit the pin on that job's own routing, not only on the product's master routing.

A scheduled job carries a frozen copy of the routing it was scheduled against, which is what protects in-flight work from routing edits made for the next order. That protection is exactly why a master-routing edit does not reach a job already on the schedule. Clear the pin on the master routing and future jobs behave, while the job in front of you refuses for exactly the same reason it refused before. Make the change on the scheduled job's routing to fix the job you are looking at.

This is the same mechanism described in routing snapshots, and it is worth internalizing once, because it explains a whole family of "I fixed it and nothing changed" moments.

Preventing the Next One

Treat a skill change as a two-field edit. When you change the required skill on a step, look at the operator selector in the same visit. It takes two seconds, and it is the entire prevention.

Use pins sparingly. The automatic option load-balances across everyone qualified and gives the scheduler room to hold your dates. A pin trades that flexibility for certainty about who, which is a good trade when the certainty is genuinely needed and a poor one when it was set out of habit. A plant with pins on a dozen routine steps will meet this symptom a dozen times.

Read the failure message. When the run stops, the message names the problem rather than failing vaguely. Reading it in full is usually faster than any diagnosis, and it is the first tier of the escalation ladder for every scheduling refusal, ahead of the anomaly report and the session log.

Keep certifications current. Expiry dates are the other way a pinned operator becomes ineligible, and that one arrives without any edit on your part. A quarterly look at expiring certifications turns a scheduling stop into a renewal reminder. How operator and skill scheduling works covers the full model.