Skip to main content
This page describes the mechanics common to all plan types. The per-type pages then only cover what’s specific to them.

​
Plan and item statuses

A plan moves through a status lifecycle. The exact statuses depend on the type, but most in-season plans follow:
Within a plan, each item carries its own status: A plan can be validated once its items are ready; the precise transitions (and which are reversible) are listed on each plan-type page.

​
Business-rule gating

When you add an item or change a plan’s status, Solya evaluates the business rules from the plan’s ruleset at that moment. Each rule can:

Block

Stops the action — the item can’t be added or the plan can’t be validated.

Warn

Lets the action proceed but surfaces a warning.

Log

Records that the rule fired, with no interruption.
Typical guards include budget (OTB) caps, plan-value limits, capacity per shop, size curves, supplier constraints (MOQ / pack multiples), and markdown calendar windows.

​
Approval workflow

Some plan types route through approval when a plan’s value exceeds a configured threshold (set via approval policies in the intelligence layer).
1

You try to validate / change status

If the plan value is over the threshold, validation is intercepted instead of proceeding.
2

An approval request is created

A Pending approval is recorded, snapshotting the plan value and the threshold. You can add a justification.
3

An approver decides

A user with the Plan approver permission Approves or Rejects the request (with a reason) from the approvals queue.
4

The plan proceeds or is sent back

On approval the status change goes through; on rejection you edit the plan and try again.
An approval can also become Expired automatically if the plan changes after the request was made (so a stale approval never applies to a different plan). Which types have an approval gate:

​
Activity & audit trail

Every plan records an immutable activity log — visible on the plan’s Activity tab. It captures plan lifecycle changes, item add/update/remove, item status changes, and the full approval lifecycle. Each entry records who (a user, a workflow, an AI scenario generator, or an API token), when, an optional reason, and the rules that applied. Labels (names of variants, shops, users…) are resolved when you read the log so they stay current.
Items added by AI recommendations or workflows are tagged with their attribution (manual vs decision-vector vs workflow), so you can always tell how a line got there.