Life Sciences Cloud Prerequisites Validation
SkillCloud & infraChecks whether a Salesforce org has the settings and permissions needed before deploying Life Sciences Cloud.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Life Sciences Cloud Prerequisites Validation skill
About this capability
Validate Life Sciences Cloud for Customer Engagement org prerequisites. Use when an admin needs to verify that all required settings, permissions, OWD sharing rules, and feature toggles are correctly configured before deploying Life Sciences Cloud. Checks user profile, permission sets, Life Sciences
What this skill tells your AI
The instructions your AI receives, as published by forcedotcom/sf-skills in skills/life-sciences-prerequisites-validate/SKILL.md and read by ahel’s review.
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-orgor 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
-
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. -
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-numberedlsc4cepackage 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."
-
Check 1 — user profile and permission sets — read
references/checks-user-and-package.mdsection "User Profile and Permission Sets" for the exact queries and validation logic. -
Managed-package gate (un-numbered hard stop) — read
references/checks-user-and-package.mdsection "Managed Package Check". If thelsc4cepackage is not installed, display the failure message and stop — do not proceed with remaining checks. -
Check 2 — Life Sciences CE settings — read
references/checks-user-and-package.mdsection "Life Sciences Customer Engagement Setup" for the exact queries. -
Check 3 — Surveys enabled — read
references/checks-user-and-package.mdsection "Surveys". -
Check 4 — OWD sharing settings — read
references/checks-org-settings.mdsection "OWD Sharing" for the exact objects and expected values. -
Check 5 — Inventory Count — read
references/checks-org-settings.mdsection "Inventory Count". -
Check 6 — Sales Account Plans — read
references/checks-org-settings.mdsection "Sales Account Plans". -
Check 7 — Care Plans — read
references/checks-org-settings.mdsection "Care Plans". -
Check 8 — Chatter Settings — read
references/checks-org-settings.mdsection "Chatter Settings". -
Check 9 — Data Protection and Privacy — read
references/checks-org-settings.mdsection "Data Protection and Privacy". -
Check 10 — Multiple Currencies — read
references/checks-org-settings.mdsection "Multiple Currencies". -
Check 11 — State and Country/Territory Picklists — read
references/checks-org-settings.mdsection "State and Country/Territory Picklists". -
Check 12 — Person Accounts — read
references/checks-org-settings.mdsection "Person Accounts".
Phase 3 — Report
- Generate consolidated report — present results in a table:
| # | 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
| Constraint | Rationale |
|---|---|
| Run all checks even if early ones fail | Admin needs the full picture to remediate in one pass |
Use sf CLI with --target-org for every query | Ensures correct org context even with multiple orgs authenticated |
| Never modify org settings | This skill validates only — it does not enable or configure anything |
| Report exact Setup navigation paths | Admins need to know where to click in Setup UI |
Gotchas
| Issue | Resolution |
|---|---|
| Some settings are not queryable via Metadata API | Use Tooling API or org settings queries where Metadata API lacks coverage |
| Person Accounts cannot be disabled once enabled | Only check if enabled; no rollback possible |
| Multiple Currencies cannot be disabled once activated | Only check if activated; warn that this is irreversible if recommending enablement |
| State/Country Picklists enabling is irreversible | Include 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
| File | When to read |
|---|---|
references/checks-user-and-package.md | During 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.md | During 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 |
Signals
- GitHub stars
- 1k
- Forks
- 342
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
life-sciences-prerequisites-validate- Source
- github.com/forcedotcom/sf-skills
github.com/forcedotcom/sf-skills