The calendar and the record live apart
Teams schedule in Google or Outlook while the work itself sits on an opportunity, a case or a work order. Neither side is ever the whole picture, and both need updating by hand.
Salesforce · Calendar & Scheduling
Scheduling that runs on your Salesforce records — not beside them.
CalendarAnything is a native Salesforce app from Mphasis Silverline that turns any object with a date or date/time field into a working calendar — drag-and-drop, colour-coded, and shareable. Twopir Consulting implements it, configures it around how your teams actually schedule, and builds the custom logic the standard package does not cover. Implementation, configuration and custom development in one engagement.
Scheduling Architecture Twopir · 2πr
Layer 01
Records With Dates
Opportunities Cases Work Orders Custom Objects Google & Outlook
Layer 02 · 2πr
CalendarAnything Layer
Calendar Design Scheduling Rules Sharing & Access Custom Extensions
Layer 03
Operating Outcomes
Visible Capacity Faster Reschedules One Source of Truth
Delivery Model Scope → Design → Configure → Extend → Support
12+
500+
250+
15+
Twopir Consulting is a Salesforce Gold Partner and HubSpot Gold Partner with 40+ consultants, delivering CRM and scheduling architecture across the US, Canada, UK, UAE, Australia and New Zealand.
Where We Deploy CalendarAnything
- CalendarAnything LWC
- CalendarAnything Classic
- Sales Cloud
- Service Cloud
- Field Service
- Experience Cloud
- Google Calendar Sync
- Outlook Sync
- Salesforce Mobile
Where scheduling breaks down in Salesforce
Almost every org we open has the same split: the work lives on Salesforce records, and the schedule lives somewhere else. The gap between the two is where the hours go.
The records you schedule are not on the calendar
A standard calendar is built around activities. The thing your team actually schedules is usually a custom object, a work order or a project milestone — and it never shows up next to the meetings.
Rescheduling costs more than it should
Moving one job means opening the record, editing a date field, saving, then telling three people. Multiply that by a week of changes and scheduling becomes a full-time coordination job.
Nobody can see real capacity
Work gets assigned from memory, so the same two people are double-booked while others sit idle. Without a shared view of who is committed when, load balancing is guesswork.
Every team needs a different view of the same data
Dispatch wants a swimlane by technician, delivery wants a Gantt by project, marketing wants a month of campaign dates. One shared calendar serves none of them, so each team rebuilds it in a spreadsheet.
People outside the org cannot see anything
Clients, contractors and partners need to know what is booked. Without a shareable view, that turns into email threads and screenshots — and a schedule that drifts out of date the moment it is sent.
What CalendarAnything is, and who it is for
CalendarAnything is a native Salesforce application, built by Mphasis Silverline, that turns any Salesforce object carrying a date or date/time field into a calendar your team can work in. Records are created, edited, cloned and rescheduled from the calendar itself rather than from a record page, with colour-coding and filtering per calendar, views that run from day and week through agenda, Gantt and swimlane, calendar sharing inside and outside the org, and synchronisation with Google and Outlook calendars.
It suits teams whose scheduling subject is a business record rather than a meeting — service dispatch, project and resource planning, campaign calendars, client appointments, delivery milestones. If a team is coordinating work that already exists in Salesforce, this is the layer that makes it visible. If the requirement is booking meetings with people outside the business, a dedicated appointment-scheduling tool is usually the better fit, and we will say so.
One naming note that matters when you are searching for documentation: the current managed package is CalendarAnything LWC, built on Lightning Web Components, and it replaced the earlier CalendarAnything Classic package. Both names are still in circulation. Product capability, licensing and packaging are set by the vendor — see the official CalendarAnything documentation from Mphasis Silverline for the current feature set, and the AppExchange listing for editions and requirements. Twopir Consulting implements and extends the product; we do not resell or license it.
| Capability | Standard Salesforce calendar | CalendarAnything | What Twopir builds on top |
|---|---|---|---|
| What appears on it | Activities by default; a user can add a limited number of personal calendars from other objects. | Any standard, custom or external object that carries a date or date/time field. | We decide which objects belong on which calendar, and model the date fields that drive them. |
| Editing from the calendar | Open the record to change a date. | Create, edit, clone and drag-and-drop records directly on the calendar. | We define which fields are editable inline and which stay locked behind your approval process. |
| Views | Day, week and month. | Day, day grouping, week, month, agenda, Gantt and swimlane. | We build the default view each team opens — saved, filtered and permissioned per role. |
| Sharing | Personal object calendars stay personal. | Calendars shared with users, groups and roles, and published externally on a site. | We map calendar sharing onto your role hierarchy so nobody sees a schedule they should not. |
| External calendars | Handled by separate Salesforce products, licensed separately. | Google and Outlook sync, so outside busy time sits beside Salesforce records. | We connect the accounts, set sync direction, and resolve the duplicate-event cases that follow. |
| Scheduling logic | None specific to the calendar. | Configuration-level rules on what shows, in what colour, to whom. | Apex, Flow and Lightning Web Components where configuration runs out — conflict rules, capacity checks, auto-assignment. |
Implement, configure, or build on top
Twopir Consulting offers all three, and they are genuinely different pieces of work. Knowing which one you need is usually the first thing a scoping call settles. You can start at any of them.
Implement
Standing the app up properly the first time: package installation, licensing, security model, and the first calendars in production with real data behind them.
- Managed package install in sandbox, then production
- Licence assignment and permission-set design
- First working calendars on your live objects
- User onboarding and admin handover
Configure
Shaping the app around how your teams actually schedule — which objects, which fields, which colours, which view each role opens on a Monday morning.
- Calendar definitions per team and per object
- Colour rules, filters and saved default views
- Sharing model mapped to your role hierarchy
- Google and Outlook sync setup and direction
Build On
Custom Salesforce development that extends the app past what configuration reaches — the scheduling logic your operation depends on and the package does not ship.
- Apex and Flow for conflict, capacity and assignment rules
- Lightning Web Components for bespoke scheduling screens
- Automation triggered by calendar-driven date changes
- API work connecting scheduling to systems outside Salesforce
Where The Boundary Sits
Configuration ends where the app's own settings end. Choosing objects, date fields, colours, filters, views, sharing and sync is configuration — declarative, upgrade-safe, and handed to your admin at the end of the engagement. The moment a requirement needs behaviour the settings do not express — refusing a drag that would double-book an engineer, recalculating a downstream milestone when one date moves, assigning work by skill and territory, pushing a confirmed slot to a system outside Salesforce — it becomes custom development in Apex, Flow or a Lightning Web Component. We will tell you which side of that line a requirement falls on before the work is quoted, because the cost, the testing and the upgrade story are different on each side.
The work that turns a package into a working schedule
Installing the app takes an afternoon. Everything below is the part that decides whether anyone still uses it in six months.
Calendar & Data Model Design
Which objects become calendars, which date fields drive them, and how records with a start and an end behave differently from single-point events.
- Object and date-field selection per calendar
- Duration, all-day and multi-day record handling
- Field-set design for what shows on a calendar item
- Naming and ownership conventions that survive growth
Scheduling Rules & Drag Behaviour
What a user is allowed to move, what happens to the record when they do, and what the system refuses outright.
- Inline-editable fields versus locked fields
- Validation and conflict handling on date change
- Downstream automation on a rescheduled record
- Capacity and workload rules where they are needed
Sharing, Permissions & Public Views
Calendars are schedules of people's time, so access design is not an afterthought. We map it to the sharing model you already have.
- Permission sets and per-calendar visibility
- Team, group and role-based calendar sharing
- External calendars published on Experience Cloud
- Review of what an external viewer can actually see
Google & Outlook Calendar Sync
So a person's real availability — including the meetings that never touch Salesforce — sits next to the work you are trying to book them for.
- Account connection and authentication setup
- Sync direction and scope decisions, made explicitly
- Duplicate and conflict resolution rules
- Privacy boundaries on personal calendar detail
Classic to LWC Migration
Moving an org from the retired Classic package to CalendarAnything LWC without losing the calendar definitions and sharing rules people rely on.
- Inventory of existing calendars, filters and sharing
- Rebuild and parallel-run validation in a sandbox
- Cutover plan with a rollback position
- Re-training on what changed in the new interface
Adoption & Ongoing Support
A calendar only works if the team lives in it. We train the people who will, and stay on for the changes that surface once real scheduling starts.
- Role-based training on the views each team uses
- Admin enablement so you own routine changes
- Post-launch tuning once real volume arrives
- Retained support as teams and objects are added
How CalendarAnything connects to your stack
The app reads Salesforce data in place — there is no separate scheduling database to keep in step. What follows is what we connect around it, and which way information travels.
Sales Cloud
Close dates, renewal dates and follow-up commitments appear as a pipeline calendar, so a slipping quarter is visible in week view rather than in a report nobody opens.
Salesforce → CalendarService Cloud
Cases and entitlement milestones render on a team calendar so support leads can see which SLAs land today and rebalance before one breaches, not after.
Salesforce ↔ CalendarField Service
Work orders and service appointments carry date/time fields, so dispatch gets a swimlane by technician and can move a job by dragging it instead of editing four records.
Salesforce ↔ CalendarGoogle Calendar
A user's Google availability sits alongside their Salesforce work, so a booking decision accounts for the meetings that were never going to reach the CRM.
Google ↔ SalesforceMicrosoft Outlook
The same availability picture for Microsoft 365 teams. We set the sync direction deliberately, because two-way by default is how duplicate events start.
Outlook ↔ SalesforceZoom
Meeting links are generated and attached to the scheduled record, so the joining detail lives on the Salesforce object rather than in somebody's sent items.
Calendar → ZoomSalesforce Mobile
Field and travelling staff view and update the same calendars from the Salesforce mobile app, so a change made on site is in the system before the van leaves.
Field → SalesforceExperience Cloud
Selected calendars are published to clients, contractors or the public site, so external parties read a live schedule instead of a screenshot that aged the moment it was sent.
Salesforce → ExternalFrom scoping call to a calendar teams trust
Five stages, one continuous engagement. Duration depends on how many objects go on calendars and how much of the requirement is custom rather than configuration — we size it in stage one, before anything is quoted.
Scope & Fit
We map how each team schedules today, which records carry the dates, and whether CalendarAnything is genuinely the right tool. If it is not, we say so at this stage.
Calendar Design
Objects, date fields, colour rules, filters, default views per role and the sharing model — agreed on paper before anything is built in the org.
Build & Configure
Package install, permission sets, calendars configured in a sandbox, external sync connected, and any custom Apex, Flow or component work built and tested.
Launch & Train
Production deployment with role-based training on the specific view each team will open, plus admin enablement so routine changes never need us.
Tune & Extend
Real scheduling volume always surfaces something the workshop did not. We stay on to tune filters, permissions and rules, and to add teams and objects as they arrive.
Scheduling architecture we have shipped
The numbers below come from a Salesforce dispatch and scheduling engagement, not from a CalendarAnything build — we have flagged that rather than blurring it. The patterns beside it are the deployments this product is repeatedly chosen for.
Transportation & Hospitality Operator
Three disconnected systems replaced with one Salesforce Service Cloud platform, rebuilding dispatch and guest coordination around a single schedule.
68% Less manual dispatch time
41% Higher guest satisfaction
90 Days from go-live to those results
Why it is on this page: the problem is the one CalendarAnything is bought to solve — dispatch decisions made across systems that could not show one schedule. The platform work there was Service Cloud rather than this app, so we have not counted it as a CalendarAnything result. It is the closest evidenced example of how we approach scheduling architecture.
Read the Full Case StudyWhat Teams Build It For
The four requests that account for most CalendarAnything engagements we scope.
- Project & resource scheduling Tasks, milestones and team availability on one shared calendar, rescheduled by dragging rather than by editing records one at a time.
- Service dispatch A swimlane by technician or crew, so the person assigning work can see the whole day and rebalance it in place.
- Campaign & content calendars Campaign records and send dates in a month or Gantt view, so marketing plans against what is already committed.
- Client-facing schedules Selected calendars published to clients or partners through Experience Cloud, replacing emailed spreadsheets.
Not a package installer. A scheduling architect.
Installing an AppExchange package is the easy part. Deciding what belongs on a calendar, who may move it, and what happens to the rest of the business when it moves — that is the work, and it is the same Salesforce architecture practice we bring to every engagement.
We scope the fit before we sell the build
If your requirement is really external appointment booking, or something Salesforce already does natively, we will tell you in the first call. A page selling an app is not the same as a partner who checks whether you need it.
We do all three scopes, so the advice is not shaped by what we can deliver
Firms that only configure will call everything configuration. We implement, configure and build custom Salesforce development, so the boundary we describe is an honest technical line rather than the edge of our capability.
We design the sharing model, not just the calendar
A calendar exposes people's time and client commitments. Getting permission sets, role-based sharing and external visibility right is part of the build here, not a question raised the week before launch.
We connect scheduling to the rest of the operation
A moved date usually means something downstream — a revised milestone, a re-assigned crew, a notified client. We build that consequence in, because a calendar that only changes itself is a calendar people stop trusting.
We stay past go-live
Scheduling is the one area where real volume immediately contradicts the workshop. We remain engaged through the first weeks of live use, when the filters, permissions and rules actually get settled.
Questions before the first call
Installing the managed package takes an afternoon. The engagement length is set by everything around it: how many objects go on calendars, how many teams need their own view, whether external calendar sync is in scope, and how much of the requirement needs custom development rather than configuration. A single team on one object with standard sharing is a short piece of work; multi-team dispatch with conflict rules and Experience Cloud publishing is not. We size it in the scoping call and quote against that scope rather than a generic timeline.
Not always, and it is worth checking before you buy anything. If your teams are scheduling meetings and activities, and each person only needs their own view, the standard calendar may be enough. The case for CalendarAnything appears when the thing you schedule is a business record rather than a meeting, when several teams need different views of the same data, when people need to reschedule by dragging rather than by editing records, or when a calendar has to be shared across roles or published to people outside the org. We would rather establish that in a scoping call than after a licence is signed.
They are two different managed packages from the same vendor. CalendarAnything LWC is the current one, rebuilt on Lightning Web Components, and Mphasis Silverline has said new functionality is being delivered there rather than on the older Classic package. If your org is still on Classic, a migration is a real project rather than an upgrade button: calendar definitions, filters, colour rules and sharing all need rebuilding and validating in a sandbox before cutover. We inventory what exists, rebuild it, run both in parallel, and keep a rollback position until the new calendars are proven.
Configuration is everything the app's own settings express: which objects and date fields drive a calendar, colour rules, filters, saved views, sharing, and external calendar sync. It is declarative, upgrade-safe, and your admin owns it after handover. Custom development starts as soon as you need behaviour those settings cannot describe — refusing a drag that would double-book someone, recalculating downstream milestones when one date moves, assigning work by skill or territory, or pushing a confirmed slot into a system outside Salesforce. That is Apex, Flow or a Lightning Web Component. We identify which side a requirement falls on before quoting, because cost, testing and the upgrade story differ on each side.
Yes to both. CalendarAnything builds calendars from any standard, custom or external object that carries a date or date/time field, which is the main reason teams choose it over a native calendar view. Calendars can also be shared internally with users, groups and roles, and published externally — typically through Experience Cloud — so clients, contractors or the public see a live schedule rather than an emailed spreadsheet. External publishing is the part worth designing carefully: we review exactly which fields an outside viewer can read before anything goes live.
No. CalendarAnything is built and licensed by Mphasis Silverline, and licensing, pricing and product roadmap are theirs — you buy the app from the vendor or through AppExchange. Twopir Consulting is a Salesforce Gold Partner and we sell the implementation service: designing the calendar architecture, configuring the app around your process, building the custom Salesforce development it does not cover, and supporting it afterwards. Keeping those two things separate matters, because it means our recommendation on whether you need the product is not a recommendation to buy something from us.
Next Step
If scheduling is what is slowing the team down, this is the right conversation
Bring us the way your teams schedule today and we will tell you what CalendarAnything would change, what it would not, and which parts are configuration rather than custom development — before anything is quoted.
Salesforce architecture, configuration & custom development under one team
