forcedotcom/sf-skills

life-sciences-prerequisites-validate

Validate Life Sciences Cloud for Customer Engagement org prerequisites.

Zobacz źródło

Jak używać

  1. Skopiuj polecenie instalacji i sprawdź źródła przed instalacją we własnym środowisku agenta.
  2. W oryginale sprawdź wymagane narzędzia, dane dostępowe i obsługiwane środowiska.
  3. Opisz dane wejściowe i oczekiwany rezultat; porównaj wynik ze źródłami.
npx skills add https://github.com/forcedotcom/sf-skills --skill life-sciences-prerequisites-validate

Przed rozpoczęciem

  • Instalacja nie obejmuje subskrypcji modelu, limitu API ani uprawnień do plików.
  • Gwiazdki i instalacje pokazują aktywność, a nie niezależny test jakości lub bezpieczeństwa.
Oryginalny dokument Skill

Treść z repozytorium z zachowaniem nagłówków, przykładów, kodu, tabel, linków i obrazów.

Life Sciences Cloud Prerequisites Validation

Validates that a Salesforce org meets all prerequisites for Life Sciences Cloud for Customer Engagement. Runs checks via the sf CLI against the currently authenticated org and produces a consolidated pass/fail report with remediation steps for any failures.

Scope

  • In scope: Validating org settings, user permissions, OWD sharing, and feature toggles required for Life Sciences Cloud CE
  • Out of scope: Automatically enabling or configuring settings that fail validation

Off-topic requests

If the user asks for something unrelated to this skill (either at the start or mid-execution), do not attempt it. Tell the user you did not understand the request, then show what you can help with: validating Life Sciences Cloud org prerequisites (this skill), and — if relevant — point them to life-sciences-territory-configure for territory setup or life-sciences-fieldsalesrep-coordinate for the full end-to-end setup. Then stop and wait.


Required Inputs

Gather before proceeding:

  • Target org: The org alias or username to validate (from sf config get target-org or user-specified)
  • Confirmation: The logged-in user must be the admin whose profile and permission sets are being validated

Workflow

All checks run sequentially. Collect all results before presenting the final report.

Phase 1 — Validate Environment

  1. Confirm org connection — run sf org display --target-org <org> to verify the org is accessible. If it fails, stop and ask the user to authenticate.
  1. Identify the logged-in user — extract the username from the org display output.

Phase 2 — Run All Prerequisite Checks

Run each check below. For each, record PASS or FAIL with the remediation steps. The checks use the canonical Check 1 – Check 12 numbering from the reference files and the final report; the managed-package check is an un-numbered hard-stop gate, not one of the 12 scored categories. Checks 1–3 (and the managed-package gate) are in references/checks-user-and-package.md; Checks 4–12 are in references/checks-org-settings.md.

STOP-GATE (report completeness). Every check MUST produce a row in the final report — a check that errors (e.g. Multi-Currency returns HTTP 400 INVALID_TYPE, or an object isn't deployed) is a FAIL row, never a skipped/omitted row or a reason to abort the run. The report's row count MUST equal the full scored-check count (12 categories, Check 1 – Check 12). The one intended early exit is the managed-package gate (the un-numbered lsc4ce package check, step 4 below) — that legitimately stops the run with the "BLOCKED" message. In every other case, a query error is the FAIL signal: record it and continue. Do NOT let a single 4xx or unexpected-shape response silently drop a row or halt the sweep — a short report reads as "fewer things to fix" when the truth is "we didn't check."
  1. Check 1 — user profile and permission sets — read references/checks-user-and-package.md section "User Profile and Permission Sets" for the exact queries and validation logic.
  1. Managed-package gate (un-numbered hard stop) — read references/checks-user-and-package.md section "Managed Package Check". If the lsc4ce package is not installed, display the failure message and stop — do not proceed with remaining checks.
  1. Check 2 — Life Sciences CE settings — read references/checks-user-and-package.md section "Life Sciences Customer Engagement Setup" for the exact queries.
  1. Check 3 — Surveys enabled — read references/checks-user-and-package.md section "Surveys".
  1. Check 4 — OWD sharing settings — read references/checks-org-settings.md section "OWD Sharing" for the exact objects and expected values.
  1. Check 5 — Inventory Count — read references/checks-org-settings.md section "Inventory Count".
  1. Check 6 — Sales Account Plans — read references/checks-org-settings.md section "Sales Account Plans".
  1. Check 7 — Care Plans — read references/checks-org-settings.md section "Care Plans".
  1. Check 8 — Chatter Settings — read references/checks-org-settings.md section "Chatter Settings".
  1. Check 9 — Data Protection and Privacy — read references/checks-org-settings.md section "Data Protection and Privacy".
  1. Check 10 — Multiple Currencies — read references/checks-org-settings.md section "Multiple Currencies".
  1. Check 11 — State and Country/Territory Picklists — read references/checks-org-settings.md section "State and Country/Territory Picklists".
  1. Check 12 — Person Accounts — read references/checks-org-settings.md section "Person Accounts".

Phase 3 — Report

  1. Generate consolidated report — present results in a table:
markdown
| # | Prerequisite                              | Status | Remediation (if failed/warning)  |
|---|-------------------------------------------|--------|----------------------------------|
| 1 | System Administrator + Permission Sets    | PASS/FAIL | <steps if failed>            |
| 2 | Life Sciences CE Enabled                  | PASS/FAIL | <steps if failed>            |
| ...                                                                                       |

Status values are PASS, FAIL, or WARNING. Most checks are PASS/FAIL. The OWD Sharing check (Check 4) is WARNING-level: when its values differ from the expected ones, report WARNING (with the recommended value in the remediation column), never FAIL — see references/checks-org-settings.md for the exact rule.

Include a summary line: X of 12 prerequisites passed. Y require action (Z warnings).

If all pass, confirm the org is ready for Life Sciences Cloud deployment.


Rules / Constraints

ConstraintRationale
Run all checks even if early ones failAdmin needs the full picture to remediate in one pass
Use sf CLI with --target-org for every queryEnsures correct org context even with multiple orgs authenticated
Never modify org settingsThis skill validates only — it does not enable or configure anything
Report exact Setup navigation pathsAdmins need to know where to click in Setup UI

Gotchas

IssueResolution
Some settings are not queryable via Metadata APIUse Tooling API or org settings queries where Metadata API lacks coverage
Person Accounts cannot be disabled once enabledOnly check if enabled; no rollback possible
Multiple Currencies cannot be disabled once activatedOnly check if activated; warn that this is irreversible if recommending enablement
State/Country Picklists enabling is irreversibleInclude this warning in remediation steps

Output Expectations

Deliverables:

  • A formatted table showing pass/fail status for all 12 prerequisite categories
  • Remediation steps (Setup navigation paths and actions) for each failed check
  • Summary count of passed vs. failed checks

Reference File Index

FileWhen to read
references/checks-user-and-package.mdDuring Phase 2 (checks 3–6) — exact sf CLI commands, expected values, and remediation for the user profile/permission-set, managed-package, Life Sciences CE feature, and survey checks
references/checks-org-settings.mdDuring Phase 2 (checks 7–15) — exact sf CLI commands, expected values, and remediation for the OWD sharing, inventory, account plans, care plans, chatter, data protection, currencies, picklists, and person-accounts checks

Powiązane zadania

z tego samego repozytorium

Więcej Skills

Wszystkie Skills
forcedotcom
Społeczność

platform-custom-application-generate

Use this skill when users need to create or configure tab-based Salesforce Custom Applications with navigation, branding, and action overrides. Trigger when users mention custom apps, application metadata, app navigation, or organizing tabs into applications. Use when users want to create app containers for tabs and pages. Do NOT use when the goal is hosting a React UI bundle in the App Launcher — use experience-ui-bundle-custom-app-generate for that case.

instalacje
1
GitHub Stars
1,1 tys.
Aktualizacja
23 paź
forcedotcom
Społeczność

platform-custom-field-generate

Use when users create, generate, or validate Salesforce Custom Field metadata. Trigger on custom fields, field types, Roll-Up Summary, Master-Detail/Lookup relationships, formula fields, picklists, dependent (controlling) picklists, referencing a value set from a field, or scoping picklist values per record type; also field deployment errors, including a record type that won't deploy without a business process. DO NOT TRIGGER for creating/customizing the value set itself — a new GlobalValueSet o

instalacje
1
GitHub Stars
1,1 tys.
Aktualizacja
23 paź
forcedotcom
Społeczność

platform-custom-metadata-type-generate

Use to create, generate, or validate Salesforce Custom Metadata Type metadata — the mdt object, fields, and deployable records. Trigger on custom metadata types, CMDT, mdt objects, .md-meta.xml files, or cross-org reference/config data; also admin-maintained mapping/lookup/crosswalk tables (config that changes without a deploy belongs in a CMDT, never hardcoded in Apex/Flow), and CMDT deploy errors. DO NOT TRIGGER for Custom Settings (use platform-custom-setting-generate), business-record object

instalacje
1
GitHub Stars
1,1 tys.
Aktualizacja
23 paź
forcedotcom
Społeczność

platform-custom-report-type-generate

Use to create, generate, or validate Salesforce Custom Report Type metadata. Trigger on custom report types, CRTs, cross-object reports, report builder data sources, exposing fields for reporting across related objects, inner vs outer joins in reports, report type categories, or deployment errors for .reportType-meta.xml files. Do NOT trigger for running, editing, or filtering existing reports; creating report folders, dashboards, or list views; or non-authoring reporting questions.

instalacje
1
GitHub Stars
1,1 tys.
Aktualizacja
23 paź