What a command cannot do
The limits that apply no matter what you type.
A command runs as you, with your permissions, through the same gates as the interface. It is not a way around anything, and it isn't a back door for administrators either.
| Limit | What happens |
|---|---|
| Your permissions apply | Rows you can't see aren't matched. Fields you can't edit are skipped and reported — not silently dropped. |
| Locks are respected | A part checked out by somebody else is refused and named in the preview. The rest of the batch continues. |
| Approvals still apply | A command can't move a released part around an open change order. |
| Lifecycle rules still apply | Fields that lock on release stay locked. |
| Everything is audited | What ran, who ran it, what changed, and what each record looked like before. |
If a command does less than you expected
Nearly always one of the above. The preview names what it skipped and why — read that list rather than assuming the command failed. A batch of 200 that reports 197 changed and 3 refused has done exactly what it should.
Undoing
There is no single undo for a command. Use --dry-run first, and --atomic when a partial result would be worse than no result. Records changed by a command follow the normal rules — revisions are still revisions, and deleted items still go to the recycle bin.
Email [email protected] and a person will pick it up. Include the part number and what you were doing — it saves a round trip.