Installation and Deployment
Released Salesforce installer, source deployment, compatibility, and rollout checks.
Release status
Unlocked package 0.3.0.1 (04tg5000000ExTFAA0) is released: promotion was completed and independently read back as IsReleased=true. It bundles Core 2.5.6 and Interface 1.9.0 and includes Reader/Editor permission sets. Package creation reported 98% Apex coverage. A clean disposable-org install succeeded. All 32 Apex test methods plus test setup passed with no failures or skips; the test run reported 99% coverage. Retrieved source/resource contents matched exactly, and all three permission sets matched semantically, including the five Event fields and three shared Task fields in Reader/Editor. Package coverage and test-run coverage are different measurements.
This exact installer still contains Core 2.5.6. The separately published Core 2.5.7 V2 timezone correction is not retroactively part of this package. Native Salesforce recurrence remains read-only in the integration; keep the documented package and recurrence boundaries when evaluating an upgrade.
Older 0.2 betas do not include the current editor, date transport or Reader/Editor sets. Do not infer their contents from a newer source README.
Prerequisites
- Lightning Experience and Lightning Web Security enabled
- An org compatible with the package and API 62.0 metadata
- Salesforce CLI and an authorized org connection for CLI deployment
- A plan for activity permissions, sharing and related-record access
Legacy Lightning Locker is unsupported. Do not work around a missing custom-element API by weakening browser or org security.
Option A: install the released unlocked package
Evaluate the release in a sandbox or disposable org before production rollout. Use the official installer for the target environment:
Or use Salesforce CLI:
sf package install --package 04tg5000000ExTFAA0 --target-org your-org-alias --wait 20Review the CLI prompts and package details before installation. Installing does not automatically assign the optional permission sets or activate a Lightning page. The version is promoted, but installing it into any org is a separate administration action. No production-org installation is implied by the release or its clean-org verification.
Option B: deploy the source distribution
Download the matching forcecalendar-salesforce-dist.zip from the Salesforce releases. Unzip it and deploy the generated Salesforce project:
cd dist
sf project deploy start --target-org your-org-aliasDeploy Apex, LWC and static resources as one matched set. Do not copy an arbitrary Interface UMD file into the org: the Salesforce build produces the combined Core/Interface resource and matching source layout.
Build from source
From the Salesforce repository:
npm ci
cd src && npm ci && cd ..
npm run build
npm test
cd dist
sf project deploy start --target-org your-org-aliasnpm test builds the bundle and exercises the real component with mocked Apex transport. It does not execute Apex or prove LWS behavior in your org.
App Builder and permissions
Drag Force Calendar onto an App, Home or Record page. Configure:
| Setting | Default | Options |
|---|---|---|
currentView | month | month, week, day |
height | 800px | CSS height |
readOnly | false | Disable UI editing and LWC persistence callbacks |
Record pages supply the context record ID. Save/activate the page through your normal deployment process. Choose the minimum suitable permission set and assign it only to intended users.
Rollout checklist
- Confirm LWS and the installed package/source versions.
- Run
ForceCalendarControllerTestandForceCalendarPermissionsTestin the target test org. - Test as intended readers/editors, including users with no related-object access.
- Confirm private/unshared records remain protected.
- Create a disposable timed event; edit it, cancel an edit, refresh, navigate and delete it.
- Test same-day/multi-day all-day dates and a DST boundary in your users' timezones.
- Check Contact/Lead and other supported record-page associations.
- Verify recurring events cannot be mutated here and
readOnlyblocks persistence. - Inspect rejected writes and refresh failures without duplicating records.
No migration rewrites existing historical all-day records. If old data is wrong, investigate its source before deciding on a separate repair.