This page is rendered from the canonical GitHub docs. Edit on GitHub.

Sally product + workflow guide

Sally is a project management system built for teams that want a clean operational surface instead of a bloated collaboration suite.

The core idea is simple:

keep the web UI low-noise and usable
keep the API real and scriptable
make agents and automations first-class citizens instead of awkward add-ons

Mental model

Think of Sally as five connected layers:

accounts
- people log in
- people can create API keys and hosted MCP keys
workspaces
- the top-level collaboration boundary
- memberships and permissions start here
projects
- work containers inside a workspace
- each project has statuses, tasks, activity, and members
tasks
- the unit of execution
- tasks can carry assignees, descriptions, labels, todos, comments, due dates, and timesheets
machine interfaces
- HTTP API
- hosted MCP at /mcp
- local stdio MCP via sally-mcp only as a parked advanced/legacy path
optional add-ons
- feature-gated modules such as Sally CRM can attach API, MCP, and web surfaces without becoming part of the core project-management workflow

Who Sally is for

Sally is especially suited to teams that:

work in delivery, operations, support, or implementation
care about self-hosting
want direct API access
want agents or scripts to read and update project state safely
dislike PM tools that hide core workflows behind decorative UI

Current features

Accounts and auth

email/password login
session tokens
personal API keys
hosted MCP keys
profile editing
profile image upload
password reset
invite acceptance flow

Workspace management

list visible workspaces
create workspaces (superadmin)
superadmin/admin access remains available even when no workspace exists
manage workspace memberships
invite members by email or copy invite links for manual delivery
resend or cancel pending invites
workspace-scoped access control

Projects

create and update projects
archive and delete projects
canonical workspace-scoped project URLs: /workspaces/:workspaceId/projects/:projectId
inline project name/description editing in the web app
default project statuses: Backlog, In Progress, Blocked, Review, Done
custom project statuses with color and task counts
Blocked uses the default red status color
project activity log
project members with owner/member/viewer roles
project viewer role for read-only access without assignee/people details
add existing workspace members to projects or invite by email/link from the project surface
client linking

Tasks

create, update, archive, delete
canonical workspace-scoped task URLs: /workspaces/:workspaceId/projects/:projectId/tasks/:taskId
move between statuses
move to another project in the same workspace from the task modal
reorder within columns
centered task modal with editable header metadata and compact task body
rich Markdown task descriptions with slash commands, quote/code styling, image upload, and connected file search
priorities
due dates with native date picker
labels with type-to-filter picker and create-on-enter
todos/checklists
comments and mentions
comments use the same rich Markdown editor surface as descriptions and render Markdown after posting
inline image upload for task descriptions and comments
permission-aware assignee, comment, and edit controls

Clients

create, view, update, delete
attach clients to projects

Notifications

task assignment notifications
comment mention notifications
in-app notification preferences
notification email delivery processing
notification links carry workspace context so task/project links work even when the user currently has another workspace selected

Enterprise cloud storage integrations

Enterprise-gated Google Drive, Microsoft 365/SharePoint/OneDrive, and Dropbox file search
instance admins configure provider OAuth credentials once from System
each user connects their own provider account from Profile or on first use in the rich editor file picker
task descriptions and comments support /googledrive, /gdrive, /sharepoint, /onedrive, and /dropbox slash commands to search accessible files and insert links

Timesheets

project and task timesheets
workspace-wide reporting
billable and validated flags
project/user/client filters
permission-aware entry editing, deletion, validation, and self-entry flows

MCP

hosted MCP endpoint at /mcp
hosted MCP keys tied to real Sally accounts
CRM tools are listed dynamically when crm.core is enabled
local stdio MCP package kept parked for advanced/legacy setups

Sally CRM and Marketing

CRM (crm.core) and Marketing (marketing.core) are included in Community by default
/crm and /marketing web routes are available without a paid license
hosted MCP tools under crm.* and Marketing campaign tools are available when the corresponding core feature is present
CRM entities: organizations, people, deals, and activities
Marketing entities: contacts, consent, submissions, messages, campaigns, deliveries, and website tokens

Editions and licenses

Community: free core with one brand, Projects, CRM, Marketing, Superadmin, and Owner access model
Pro: up to 3 brands, custom workspace roles, enforced 2FA policy, API/MCP key expiry/scope policy
Business: up to 10 brands plus Pro and advanced governance/security/integration features such as SAML/SSO, audit log, session policy, automation governance, CI, and cloud storage integrations
Enterprise: unlimited brands plus the full Business feature set
Paid editions require a real license minted by the Sally license server. Sally does not support unlocking paid editions with an environment variable.

How Sally usually gets used

Human-first workflow

sign in
pick a workspace
create or open a project
define statuses if the defaults are not enough
create tasks and assign owners
track progress on board/project/task pages
log time when needed

Agent-first workflow

mint an API key or hosted MCP key
select the correct workspace
list projects or board state
create/update tasks, comments, labels, todos, or timesheets
leave the web UI as the human control surface

Mixed workflow

A typical real team does both:

humans work in the UI
scripts sync external state
agents summarize, update, triage, and create tasks
owners keep control via Sally's normal role model

Roles and permissions

There are two main permission layers:

Workspace roles

Community UI exposes OWNER only for workspace/project assignment, plus platform SUPERADMIN
Pro, Business, and Enterprise add custom workspace roles with read/write/admin permissions for Projects, CRM, Marketing, and System
MEMBER and VIEWER may still exist in older data or API-level compatibility handling, but assigning non-owner built-in roles is paid-tier gated

Project roles

OWNER
MEMBER
VIEWER

General rule of thumb:

owners manage structure and membership
members do normal project work
viewers can read the project and tasks, but cannot edit anything and do not see assignee/people details
the web app hides or disables actions based on the effective permission decision instead of exposing a broad editable surface to everyone

For exact behavior and edge cases, use:

docs/api.md

Hosted MCP vs local stdio MCP

Hosted MCP (`/mcp`)

Use this when you want:

the simplest client setup
remote access through your Sally domain
hosted MCP keys managed inside Sally

Local stdio MCP (`sally-mcp`)