Prompt Guide for Salsa GraphQL MCP

Use these prompts as starting points for questions about employers, workers and payroll through Salsa's GraphQL MCP server. Replace the bracketed placeholders with a business name or Salsa ID, then paste the prompt into your MCP-enabled assistant.

Tips for better results

  • Use Salsa IDs when you have them. An employer ID (er_...) or worker ID (wr_...) is more reliable than a name search. When you give a name, ask the assistant to confirm the match if more than one result comes back.
  • Ask for IDs in the answer. Ask the assistant to include the Salsa IDs and external IDs behind its answer so you can follow up or check them.
  • Don't let a missing field stop the assistant. The pre-built tools don't return every field. Tell the assistant to use search or introspect to find a field in the schema before it concludes the information isn't available.
  • Ask it to separate facts from judgment. Ask the assistant to label which statements come directly from Salsa data and which are its own conclusions.
  • Confirm before changes. The MCP server can change data unless you connect in read-only mode. When a prompt might lead to a change, ask the assistant to show you the exact change and wait for your confirmation.
  • Narrow broad questions. A question that covers many employers or workers makes many requests and can reach rate limits. Filter by partner, status or country where you can.

Quick lookups

Find an employer:

Find the employer [business name] and return its business name, Salsa employer ID, external ID, and account standing.

Check whether an employer can run payroll:

For employer [er_ID], show its pay-workers readiness status and every outstanding requirement. For each requirement, say whether the employer, Salsa, or our team needs to act.

Review a payroll run:

List the five most recent payroll runs for employer [er_ID] with their status and totals. Then show the per-worker breakdown of the most recent run.

Check a worker's year-to-date totals:

What are the year-to-date gross pay, net pay, and worker tax totals for worker [wr_ID]? Break them down by pay date.

Check the next pay date:

For employer [er_ID], find the next expected pay date for each recurring pay group and the submission cutoff for that pay date.

Explore the schema:

Use search to find the GraphQL types that describe an employer's pay groups. Summarize the fields available and give me an example query, validated against the schema, that returns them for one employer.

Before making a change

If you only need to look things up, connect in read-only mode and nothing can change. On a read-write connection, add this line to any prompt that could create, update or delete data:

Before you create, update, or delete anything, show me the exact change, including the records affected, and wait for me to confirm.

Support workflows

These longer prompts handle multi-step support work. Each one does a specific job, returns the Salsa IDs needed for follow-up, and separates facts available in GraphQL from conclusions that still need human judgment or evidence outside Salsa. In the prompts, "us" means your team: the partner supporting the employer.

All four prompts only read data, so they work in read-only mode. Replace the bracketed placeholder, then copy the complete prompt into your assistant.

1. Employer readiness check

Use this when: An employer is approaching payroll and support needs a single view of anything that could prevent it from paying workers successfully.

What it produces: Confirmed blockers, advisory gaps, the next payroll deadline, ownership of each action, and coverage counts.

For employer [business name or er_ID], determine what could prevent its next payroll and what our customer experience should address first.

Use the pre-built Salsa tools first. If they omit a requested field, use search or introspect to inspect the relevant GraphQL types, build and validate a read-only query, and then execute it. Do not treat information as unavailable merely because a pre-built tool omitted it.

If given an er_ID, resolve it directly. If given a business name, search for it and ask for confirmation only if multiple employers match.

Check:

- Account standing and outstanding requirements
- Employer pay-workers readiness and outstanding requirements
- Every active worker’s payment readiness and requirements
- Whether a funding account is enabled, verified, and authorized
- Recurring pay group, next expected pay date, and requestedPayDateSubmissionCutoff from payDateFeasibility
- Payroll-history migration status and unresolved ACTION_NEEDED reason
- For Canadian workers, missing time-off assignments where the employer has a relevant configured policy
- Existing payroll runs, invalid workers, and excluded workers

Return:

- Business name, Salsa employer ID, and external ID
- Confirmed blockers and advisory gaps
- Next expected pay date and submission cutoff
- Whether each next action belongs to us, the employer, or Salsa
- The smallest useful next action
- Coverage counts for workers and payroll runs checked

Distinguish GraphQL facts from outside evidence or payroll judgment.

2. Actionable insights from the onboarding queue

Use this when: Customer experience wants a prioritized work queue focused on employers most likely to miss their first or second payroll—not simply the oldest onboarding accounts.

What it produces: A ranked list of 20 employers, the evidence creating urgency, the next submission cutoff, and who owns the next action.

Identify 20 production employers where support attention is most likely to prevent a delayed first or second payroll.

Use Salsa’s employer activation guide at https://docs.salsa.dev/docs/track-and-engage-employers-through-activation to interpret the onboarding journey. Treat pay-workers readiness and account standing as separate tracks:

- ONBOARDING means initial payroll setup is incomplete.
- IMPLEMENTATION means prior payroll history still needs to be imported or processed.
- PARTIALLY_READY means payroll can run despite remaining requirements.
- IN_REVIEW ordinarily indicates Salsa-owned review.
- RESTRICTED prevents payroll until its requirements are resolved.

Use the pre-built Salsa tools first. If they omit fields needed for the checks below, use search or introspect to inspect the relevant GraphQL types, build and validate read-only queries, and then execute them. Do not treat information as unavailable merely because a pre-built tool omitted it.

Review production employers whose pay-workers readiness is ONBOARDING, IMPLEMENTATION, or PARTIALLY_READY. Exclude demo and cancelled employers.

For each employer, inspect:

- capabilities.payWorkers.status and its outstanding requirements
- accountStanding.status and its outstanding requirements
- Payroll-history migration status and any ACTION_NEEDED reason
- Whether a funding account is enabled, verified, and authorized
- Signatory and recurring pay-group setup
- Actual pay-group schedule, next expected pay date, and requestedPayDateSubmissionCutoff from payDateFeasibility
- Existing payroll runs and whether an expected period lacks a covering run
- For Canadian workers, missing time-off assignments only where the employer has a relevant configured time-off policy
- Earliest initial pay date on a pay group containing at least one worker

Rank employers primarily by the risk of missing an upcoming payroll:

1. Submission cutoff passed or approaching without a submitted payroll run
2. RESTRICTED account standing
3. Employer-owned requirement blocking readiness
4. Migration ACTION_NEEDED
5. Missing ready funding account, signatory, recurring pay group, or required payroll history
6. Salsa-owned review that threatens the upcoming payroll date
7. Advisory setup gaps that do not currently block payroll
8. Earliest initial pay date on a pay group containing at least one worker

Do not rank an employer highly merely because it is old, IN_REVIEW, or PARTIALLY_READY. Use its requirements and payroll schedule to determine whether action is needed.

For each result, return:

- Business name, Salsa employer ID, and external ID
- Pay-workers readiness and account standing
- Next expected pay date and submission cutoff
- Exact evidence creating urgency
- Whether the next action belongs to us, the employer, or Salsa
- The smallest useful next action
- Confidence: confirmed blocker, advisory, or incomplete

End with coverage counts: employers reviewed, workers checked where relevant, payroll runs checked, and any incomplete reads.

3. RFI and risk-review check

Use this when: An employer is in review or restricted, and support needs to understand the exact RFI or risk-review state, who must act, and whether payroll is in danger.

What it produces: The review state supported by GraphQL, action ownership, and cutoff impact.

For employer [business name or er_ID], determine its exact current risk-review and request-for-information state and whether it threatens the next payroll.

Use the pre-built Salsa tools first. If they omit requested risk-review, account-standing, requirement, classification, or resolution fields, use search or introspect to inspect the relevant GraphQL types, build and validate a read-only query, and then execute it. Check the schema before concluding that information is unavailable.

If given an er_ID, resolve it directly. If given a business name, search for it and ask for confirmation only if multiple employers match.

Check:

- accountStanding.status and its requirements
- Employer risk-review requirements
- Classification tags
- Current review status
- Resolution and resolution time
- Next expected pay date and requestedPayDateSubmissionCutoff from payDateFeasibility
- Whether payroll confirmation is currently blocked

Return:

- Business name, Salsa employer ID, and external ID
- Exact GraphQL evidence
- Whether the outstanding action belongs to us, the employer, or Salsa
- Whether the review threatens the next submission cutoff
- The smallest useful next action

Only report document or identity-verification requirements that GraphQL explicitly exposes. If the requested document, rejection reason, or verification link remains unavailable after checking the schema, say so and identify the remaining lookup needed.

4. Payroll-history migration check

Use this when: An employer previously ran payroll elsewhere and support needs to know whether migration work or an uncovered pay period could delay the first Salsa payroll.

What it produces: The migration state, schedule-based gap analysis, next deadline, action owner, and smallest next step.

For employer [business name or er_ID], determine whether payroll-history migration could delay its first Salsa payroll or leave an uncovered pay period.

Use the pre-built Salsa tools first. If they omit requested migration, import, pay-group, or payroll-run fields, use search or introspect to inspect the relevant GraphQL types, build and validate a read-only query, and then execute it. Do not declare information unavailable until the schema has been checked.

If given an er_ID, resolve it directly. If given a business name, search for it and ask for confirmation only if multiple employers match.

Report:

- Business name, Salsa employer ID, and external ID
- Declared prior payroll provider
- Provision method
- Projected first pay date
- Current migration status and status timeline
- Unresolved ACTION_NEEDED reason
- Payroll-history import records
- Pay groups and their recorded schedules
- Next expected pay date and requestedPayDateSubmissionCutoff from payDateFeasibility
- Existing payroll runs

Classify the current state as:

- Waiting for the employer
- Waiting for import processing
- Import completed
- No prior payroll history
- Possible schedule gap requiring human verification

Identify whether the next action belongs to us, the employer, or Salsa, and give the smallest useful next action. Do not call a period missing unless the recorded pay schedule and payroll or import records prove it.

Treat the assistant's recommendations as support triage, not authoritative payroll, tax or legal determinations.