A classic workflow scoped to User

Workflow applies only to rows its owner owns.

An enabled classic workflow has its scope set to User, so it acts only on rows its owner owns and does nothing when anyone else's row meets its trigger. User is the scope a new workflow gets by default, so it can read as automation for the whole table while acting on one person's rows.

It may be exactly what the owner intended, a personal reminder for example, and nothing is broken either way, which is why it is reported at Low. Workflows that users start on demand, and workflows that can run as a child process, are not reported, because there a person or a parent process picks the row.

List activated classic workflows and their Scope. Any automatic workflow scoped to User, and not also available on demand or as a child process, is the finding. The symptom is automation that works when its owner tests it and does nothing for everyone else.

Ask the owner whether it should act on every row. If so, deactivate it, widen the scope, and activate it again; if not, record the intent in its description.

This one is environment health, so it carries a plain label and no control mapping. Presenting an operational gap as a security finding would make the real security findings harder to trust, so we keep the two apart.

• A plugin step that re-triggers itself on every save
• A cloud flow that re-triggers itself on every run
• Two plugin steps at the same execution order writing one column
• Two flows writing the same column on the same trigger