PowerSolver 2.0 Concepts Guide

What is PowerSolver?

PowerSolver is a planning optimization tool that automatically finds the best way to assign resources to tasks while following your business rules.

Think of it as: An intelligent assistant that considers thousands of possibilities and selects the best arrangement that meets all your requirements.

Example: Instead of spending hours manually creating a staff schedule, PowerSolver does it in seconds — ensuring no one works overlapping shifts, skills match requirements, and workload is balanced fairly.

The 6 Core Concepts

Every planning problem in PowerSolver consists of these six building blocks:

1. Entities — "What Needs to Be Assigned?"

Entities are the items that need decisions made about them.

Examples by Problem Type

What Makes Up an Entity?

Each entity has properties that describe it:

Entity: "Task-001"
├── Name: "Implement Login Page"
├── Duration: 4 hours
├── Priority: High
├── Required Skills: ["JavaScript", "React"]
└── Deadline: January 15, 2026

Your job: Define what entities you have and what properties each one has.

Standard vs Custom Properties

PowerSolver supports two types of properties:

→ See: Custom Properties Reference for complete details on using custom properties with constraints.

2. Planning Variables — "What Decisions Are You Making?"

Planning Variables define what choices PowerSolver needs to make for each entity.

Simple Example

For a task assignment problem:

• Entity: Task
• Planning Variable: "Which developer is assigned to this task?"
• Result: Task-001 → Alice

Multiple Variables (N-Variable Planning)

PowerSolver supports 1 to 4 planning variables per entity:

⚠️ CRITICAL: Two Types of Variables (BASIC vs LIST)

BASIC Variables — One Entity Gets One Value

Use for: Task Assignment, Employee Rostering, Timetabling, Maintenance Scheduling

How it works: Each entity is assigned to exactly ONE value per variable.

BASIC Variable Example (Task Assignment):
┌─────────────┐        ┌─────────────┐
│   Task 1    │───────▶│   Alice     │
└─────────────┘        └─────────────┘

┌─────────────┐        ┌─────────────┐
│   Task 2    │───────▶│    Bob      │
└─────────────┘        └─────────────┘

┌─────────────┐        ┌─────────────┐
│   Task 3    │───────▶│   Alice     │
└─────────────┘        └─────────────┘

Each task → ONE developer
(Multiple tasks CAN go to the same developer)

LIST Variables — One Entity Gets Multiple Values

Use for: Vehicle Routing (and similar "collect multiple items" problems)

How it works: Each entity is assigned a LIST of values in a specific order.

LIST Variable Example (Vehicle Routing):
┌─────────────┐        ┌─────────────────────────────┐
│  Vehicle 1  │───────▶│ [Stop A, Stop B, Stop C]    │
└─────────────┘        └─────────────────────────────┘

┌─────────────┐        ┌─────────────────────────────┐
│  Vehicle 2  │───────▶│ [Stop D, Stop E]            │
└─────────────┘        └─────────────────────────────┘

Each vehicle → MULTIPLE stops (in order)
Each stop goes to exactly ONE vehicle

When to Use Which?

❌ Common Mistake: Using Wrong Variable Type

Vehicle 1 → Stop A    ❌ Only one stop per vehicle!
Vehicle 2 → Stop B

Vehicle 1 → [Stop A, Stop B, Stop C]    ✅ Multiple stops per vehicle
Vehicle 2 → [Stop D, Stop E]

💡 Rule of Thumb: If each entity needs to "collect" or "visit" multiple things in order, use LIST. Otherwise, use BASIC.

Shadow Variables — Auto-Updating Labels

When PowerSolver schedules your tasks, you give it two kinds of facts: the people doing the work (with their start-of-day) and the tasks being done (with their durations). PowerSolver then has to make some decisions — who gets which task, in what order — but it also has to compute a bunch of follow-on facts you care about: when does this task start?, who's right before me in the queue?, which person did this task land on?.

Those follow-on facts are called shadow variables. They have three properties that make them useful:

• Computed automatically — you never type a value for one. PowerSolver fills them in.
• Always current — every time PowerSolver tries a different placement, all the shadow values update by themselves, so they match the current schedule.
• What everything else reads — the Solution Gantt, the Insights load chart, the Explain score breakdown all read shadow values, not the raw list.

Think of them as labels stuck on each task that rewrite themselves the moment the task moves.

The two you'll always see

For any "Consecutive on a host" problem, every task automatically carries these:

You declare these by name when you turn on sequence mode (or click Apply default template in Step 3). PowerSolver maintains them for free as the schedule changes. Two more are available if you ever need them — next (the task after me) and index (my 0-based position in the queue) — but most scheduling problems don't.

Derived shadows — the ones with formulas

A derived shadow is a follow-on fact you describe, with a tiny formula. PowerSolver re-runs the formula every time the schedule changes, so the value is always up to date.

The two formulas that come with "Consecutive on a host" are:

startTime = previous?.endTime ?? host.startTime
endTime   = startTime + this.duration

Read aloud:

• "My start time is the previous task's end time — or, if I'm first in the queue, my host's start-of-day."
• "My end time is my start time plus my own duration."

That pair is enough to roll a whole day's schedule forward, for any number of people and any number of tasks. You write nothing else, and startTime / endTime appear on every task in the output.

The formula language is intentionally small: you can read values along a path (previous.endTime), guard against missing values (?., ??), and do arithmetic on numbers, durations, and datetimes. No loops, no function calls. If a real problem needs something the formulas can't express, a new built-in rule is added in powersolver-api rather than complicating the formula language.

For a walk-through of a real placement — what the user types, what PowerSolver decides, and the exact startTime / endTime values the derived shadows produce — see Understanding "Consecutive on a host" in the Wizard Guide.

3. Planning Values — "What Are Your Options?"

Planning Values are the resources or options you can assign to entities.

Examples

What Makes Up a Value?

Each value has properties that affect constraints:

Value: "Alice Chen"
├── Skills: ["JavaScript", "React", "Python"]
├── Max Hours Per Day: 8
├── Availability: Mon-Fri, 9:00-17:00
└── Hourly Rate: $75

Your job: Define all available options and their properties.

4. Constraints — "What Are the Rules?"

Constraints are rules that your solution must follow (or should try to follow).

The Three Levels of Constraints

Hard Constraints — Non-Negotiable Rules

These are your absolute requirements. A solution that violates ANY hard constraint is unusable.

Examples:

• ❌ "An employee cannot work two shifts at the same time"
• ❌ "A task requiring Java skills must be assigned to someone who knows Java"
• ❌ "Vehicle capacity cannot be exceeded"
• ❌ "All tasks must be completed before their deadlines"

Medium Constraints — Resource Management

These help when you have limited resources and can't satisfy everything.

Examples:

• 📊 "Assign as many tasks as possible" (when you don't have enough staff)
• 📊 "Cover as many shifts as possible" (when understaffed)
• 📊 "Visit as many customers as possible" (when fleet is limited)

Soft Constraints — Optimization Goals

These make your solution better but aren't mandatory.

Examples:

• ⭐ "Distribute workload evenly across employees"
• ⭐ "Minimize total travel distance"
• ⭐ "Honor employee shift preferences when possible"
• ⭐ "Minimize overtime costs"

Constraint Decision Guide

5. Score — "How Good Is This Solution?"

Every solution PowerSolver produces has a score that tells you how well it meets your constraints.

Score Format

Score: -2hard / -1medium / -350soft
       │        │          │
       │        │          └── Soft constraint penalties
       │        └── Medium constraint violations
       └── Hard constraint violations (MUST be 0!)

Understanding Scores

The Golden Rule

A solution is only valid (feasible) if the hard score is exactly 0.

If you see -1hard or worse, the solution violates must-have rules and cannot be used.

Comparing Scores

When comparing two valid solutions:

1. First: Compare hard scores (must both be 0)
2. Then: Compare medium scores (less negative is better)
3. Finally: Compare soft scores (less negative is better)

Solution A: 0hard / -2medium / -500soft
Solution B: 0hard / -1medium / -800soft

Winner: Solution B (better medium score, even though soft is worse)

6. Solution — "The Final Result"

A solution is the complete set of assignments that PowerSolver produces.

What You Get

{
  "score": "0hard / 0medium / -450soft",
  "assignments": [
    { "entity": "Task-001", "developer": "Alice", "timeslot": "Monday 9:00" },
    { "entity": "Task-002", "developer": "Bob", "timeslot": "Monday 9:00" },
    { "entity": "Task-003", "developer": "Alice", "timeslot": "Monday 14:00" }
  ]
}

Solution States

Putting It All Together: A Complete Example

Scenario: Task Assignment (2 Variables)

Business Problem: Assign 3 development tasks to 2 developers in 2 time slots.

Step 1: Define Entities (Tasks)

Step 2: Define Variables

Step 3: Define Values

Developers:

Time Slots:

Step 4: Define Constraints

Step 5: PowerSolver Finds Solution

Score: 0hard / 0medium / -50soft (feasible!)

Assignments:
  Task 1 → Alice + Monday 9:00
  Task 2 → Alice + Monday 14:00
  Task 3 → Bob + Monday 9:00

Step 6: Verify the Solution

• ✅ Skill Match: Alice has Java (Task 1), Alice has React (Task 2), Bob has Java (Task 3)
• ✅ No Overlap: Alice does Task 1 at 9:00, Task 2 at 14:00 — no overlap
• ✅ Deadline: All tasks before their deadlines
• ⚠️ Balance: Alice has 2 tasks, Bob has 1 — small soft penalty

What PowerSolver Cannot Do (Limitations)

Understanding limitations helps you model problems correctly.

❌ Cannot Mix BASIC and LIST Variables on Same Entity

If you need LIST variables (Vehicle Routing), ALL variables must be designed for that pattern.

❌ Cannot Handle Infinite Options

You must define a finite list of values. PowerSolver cannot search infinite possibilities.

❌ Cannot Guarantee Perfect Solutions for Very Large Problems

With thousands of entities, PowerSolver finds very good solutions — but may not find the mathematically perfect one within the time limit.

❌ Cannot Make Business Decisions for You

PowerSolver optimizes within the rules you define. You must decide:

• What constraints matter
• How important each constraint is (hard/medium/soft)
• What trade-offs are acceptable

Quick Reference: Problem Type Modeling

Next Steps

Now that you understand the concepts:

1. Quick Start Guide — Follow step-by-step tutorials
2. User Guide — Learn how to use PowerSolver
3. Wizard User Guide — Screen-by-screen walkthrough