Salesforce / Lightning + Apex / released 0.3.0.1

Your Events.
In their element.

Put a real calendar on your Lightning pages, beside the customer and record context your team already uses. Standard Salesforce Events, an adaptable interface, and access enforced in Apex.

Actual Lightning capture / synthetic sample dataMonth · week · day
Genuine Salesforce Lightning calendar showing synthetic appointments in a week view
Week view
Week view. Real Salesforce Lightning demo with synthetic sample data.
Released installer 0.3.0.1Package: Core 2.5.6 / Interface 1.9.0Website demo: Core 2.5.7 / Interface 1.9.1

A calendar over standard Events

Create, read, edit, delete, and navigate accessible Salesforce Event records. Record-page context follows supported Event relationships.

Bundled inside your org

The LWC loads Core and Interface from a static resource. Calendar assets do not need a runtime CDN.

Validate the access model

Sharing and user-mode access apply in Apex. Configure permissions intentionally and test representative users before rollout.

The integration, end to end

A familiar record.
A richer way to work with it.

The calendar is the interface. Salesforce remains the record system.

01

Salesforce Event

Your records, relationships, sharing, and org rules.

02

Apex controller

Queries and writes with sharing and user-mode CRUD/FLS enforcement.

03

Lightning component

Loads the bundle, requests the visible range, and forwards changes.

04

Calendar UI

Month, week, day, and event forms. The response returns through the same data boundary.

Lightning Web Security is required. Legacy Lightning Locker is not supported for the third-party custom elements used here. Official Salesforce guidance

From package to Lightning page

Start in a sandbox.
Roll out deliberately.

Released unlocked package 0.3.0.1 passed a clean install and 32 Apex test methods, with 98% package coverage. These checks do not replace validation in your own org.

01

Check the prerequisites

Use Lightning Experience with Lightning Web Security enabled. An admin or developer needs package installation rights and access to Lightning App Builder. Confirm that standard Event records fit your use case.

02

Install the released package

Choose Install for Admins Only, then grant access to the intended users. Keep a record of the exact version you test.

Production installation is available. Complete your sandbox checks first. Package 0.3.0.1 freezes Core 2.5.6 and Interface 1.9.0; npm updates do not change that package.

03

Add the component and assign access

  1. Open Setup → Lightning App Builder and edit an App, Home, or Record page.
  2. Add ForceCalendar Demo to check sample-data rendering. It has no Apex data access.
  3. Add Force Calendar for actual Event records, then save and activate the page for your intended users.
  4. Assign the minimum permission set needed and verify access to the related records.
04

Validate the whole interaction

Use disposable synthetic records with a representative non-admin user. Test create, edit, cancel, confirmed delete, reload, navigation, all-day dates, Record page relationships, read-only behavior, and denied access. Check your org’s validation rules and flows, then run the Apex tests.

Deploy the same version you validated, repeat page activation and permission assignments, and verify the production experience as an intended user.

Access is part of the integration

Give each user
the right surface area.

No permission set is assigned automatically. Read-only UI is a convenience; Apex and Salesforce permissions enforce data access.

Full permissions reference

ForceCalendarAccess

Controller access only. Use it when your org manages activity and field permissions separately.

ForceCalendarReader

Controller access, Access Activities, and read access to the five configurable fields used by the component.

ForceCalendarEditor

Reader access plus Edit Events and field edit access. Edit Events permits create, update, and delete subject to sharing.

Permission sets are additive: Reader does not revoke permissions elsewhere. These sets do not grant related Account, Contact, or Lead access, Edit Tasks, View All, or Modify All. Access Activities applies beyond this calendar. Salesforce shares Description, WhoId, and WhatId permissions with Task; Subject, StartDateTime, and EndDateTime do not have independent configurable field permissions.

Configuration & boundaries

Know what your
page will do.

currentView

month / week / day. The initial view defaults to month.

height

800px by default. Choose an appropriate CSS height and test smaller screens.

readOnly

Disables editing and dragging while preserving navigation and selection. Save callbacks are also blocked.

App, Home, and Record pages

App and Home pages show accessible Events in the requested date range; this guide configures no owner-only filter. Record pages filter through WhoId or WhatId. Contact and Lead contexts use WhoId; supported related records use WhatId. Access to that object and record is still required. Related child records are not automatically included.

Recurrence, dates, and query limits

Native recurring Salesforce Events remain read-only here; manage series and occurrences in Salesforce Calendar. All-day events use inclusive civil dates. The query returns at most 1,000 records per requested date range. Tasks, custom-object calendars, and resource booking are not configured by this integration guide.

What was actually verified?

The production LWC was tested against actual Salesforce Events using disposable synthetic fixtures, including editing, confirmed deletion, refresh, navigation, and inclusive all-day dates. Restricted-user behavior has isolated Apex tests; an actual restricted-user Lightning session has not been tested. The screenshots below show an earlier synthetic demo capture, not the installation or permission tests.

Alternative / deploy from source

Keep the full stack
on one revision.

Deploy the LWC, Apex controller, and static resource together. Build dependencies live in both the repository root and src directory.

Use an authenticated sandbox alias. A source checkout and its resolved dependencies can differ from the released package.

Terminal
git clone https://github.com/forcecalendar/salesforce.git
cd salesforce
npm ci
cd src
npm ci
cd ..
npm run build
cd dist
sf project deploy start --source-dir force-app --target-org your-sandbox-alias
sf apex run test --class-names ForceCalendarControllerTest --target-org your-sandbox-alias --result-format human --wait 10

Genuine Lightning specimens

A view for the way you work.

Core 2.5.5 · Interface 1.8.1 · October 2026 captures. Real Lightning pixels with synthetic sample data; they do not verify the current package or your org’s data access.

Explore before you integrate

Try the calendar in the playground.

Open playground