How EspoCRM working time calendars for teams and holidays affect scheduling
EspoCRM working time calendars define when users and teams are available, so that meetings, due dates and assignments reflect who is actually working. According to the EspoCRM working time calendar documentation, as of v7.3 a calendar holds a weekly schedule with hours for each weekday, plus working and non-working day exceptions that can apply to individual users, to teams or to the whole organization. A sales or service team needs this when meeting slots, follow-up deadlines or case response windows depend on who is on shift, who is on leave and which public holidays apply in each country or office. If the whole company works the same hours and holidays, the organization-wide default may be enough and the extra setup is not justified.
The practical decision is which level owns each exception. A public holiday usually belongs to the organization or to a regional team, while annual leave belongs to one user. Mapping holidays by office, then recording leave per person, keeps a team calendar from blocking scheduling for colleagues who are still working. Ask your project lead to confirm how the calendar is consulted by the features your teams use, because the documentation describes the calendar itself and the behavior of each scheduling feature should be tested in your own instance before go-live.
Plan the calendar with the people who own leave and holiday data, such as HR or regional managers, and agree who maintains exceptions each year. Test with a small set of records: book a meeting across a holiday, mark a user as absent and check what changes in the scheduling views. Treat the calendar as shared configuration that needs a named owner, because stale holiday data is a common source of missed follow-ups. The EspoCRM working time calendar documentation is the starting point for confirming field names and exception types in the version you run.
Calendar scope options and when each fits
This table compares organization-wide, team and individual user working time calendars in EspoCRM across typical use, maintenance effort and the risk of drift. Read each column as a setup choice, then confirm the exact behavior of your EspoCRM version before you commit to a pattern.
| Scope | Typical use | Maintenance effort | Risk of drift |
|---|---|---|---|
| Organization-wide calendar | A single company-wide working week and public holidays shared by most staff | Low: one schedule to update each year, confirm in your version | Low, but staff in other regions may be scheduled against the wrong holidays |
| Team calendar | Sales or support teams that work different hours or shifts from the rest of the company | Medium: each team's schedule and exceptions must be kept current | Medium: a team's leave changes may not be reflected if owners do not review them |
| Individual user calendar | Part-time staff, contractors or people on personal leave or unusual hours | High: every exception is entered by hand or by an administrator | High: records go stale when leave is not entered or is entered late |
| Holidays and non-working exceptions | Public holidays, company closures and approved leave that override the weekly schedule | Medium to high: depends on how many exceptions are maintained and by whom | High if exceptions have no owner or review date |
| Scheduling and availability views | Booking meetings, calls and tasks without suggesting unavailable times | Depends on the calendar scope chosen and how much the team relies on it | Confirm whether calendar data is used by every scheduling feature in your version |
| Recommended starting point | Organization-wide default, then team calendars only where hours genuinely differ | Keep the number of separate calendars small | Assign an owner and a yearly review for every calendar you create |
Setting up calendars for teams and holidays
This sequence turns a business's working pattern, team structure and holiday calendar into EspoCRM working time calendars, so that scheduling views show who is available and when. Each step ends with a check so that gaps are found before users rely on the data.
Confirm the EspoCRM release in use
Confirm the exact EspoCRM version your instance runs, either from the administration area or the installed release, and check that it is a version where working time calendars are available. The documented feature is described as of v7.3, so any release at or above that line should include it, but confirm the menu paths and field names in the user guide for your own version before configuring anything. Record the version in the project notes, since the screens and settings can differ between releases. Done when the version is written down and the working time calendar screens are visible in your instance.
Agree team structure and time zones
Work with operations, HR and team leads to list the teams that need their own calendars, the users who sit outside those teams, and the time zones each group works in. Ask the business whether any team follows a shifted or split week, and whether leave is approved by a manager, a team or a central HR function, because that decides who maintains each exception. Confirm which time zone the organization default uses, and how users in other zones will be shown. Done when a signed-off table lists each team, its members, its time zone and the named owner of its leave data.
Define the organization default week
In the working time calendar settings, create the organization-wide calendar that every user inherits unless a narrower calendar applies. Enter the working hours for each weekday, leaving non-working days empty, and check the result against the written working pattern agreed in the previous step. Keep this default conservative and general, since team and user exceptions should carry the differences. Done when the default week matches the agreed pattern on every weekday, and a sample user without a team calendar shows that schedule in a scheduling view.
Create team calendars for different working patterns
Create a working time calendar for each team whose hours differ from the organization default, and assign it to that team. Use the same weekday structure so that the team schedule can be compared with the default at a glance. Confirm that each team calendar is linked to the correct team and that no team is left on a calendar it does not need. Done when every team with a distinct pattern has its own calendar and a test user from each team shows the expected hours.
Add user exceptions for leave and public holidays
Add non-working day exceptions for public holidays at the organization level, and add individual exceptions for approved leave, part-time arrangements or one-off working days at the user level. Record the leave source, such as the HR approval reference, in the notes so that the data can be audited. Limit exceptions to what the business has confirmed, and ask HR to review the list before go-live. Done when the holidays for the current period and the approved leave for the pilot users appear as non-working days, and a list of exceptions matches the source document.
Check that scheduling views reflect the calendars
Open a scheduling view, such as a calendar or a meeting booking screen, and check that each test user shows the correct available and unavailable times. Compare a user on the default calendar, a user on a team calendar and a user with a leave exception, and confirm that the exception overrides the working pattern for its dates. Also check a date that falls on a public holiday for a user in a different time zone. Done when each test case behaves as the signed-off table predicts, and any mismatch is logged with the record and date.
Verify with a test record and sign off
Create a test meeting or task for a user on a holiday and for a user on a working day, and confirm that the scheduling behavior matches the calendars you configured. Ask the team leads and HR contact to review the test results and the exception list, then remove test records after sign-off. Document the release version, the calendar names, the owners of each exception type and the process for adding future leave, so that the configuration can be maintained. Done when the test records pass, the owners have approved the configuration in writing and the maintenance process is documented.
Where working time calendars change what users see
Working time calendars do not change data on their own. They change how dates, availability and reports are read across the CRM, so the same schedule has to be applied consistently to people who plan meetings, own records and report on activity. The cards below cover the places where that difference shows up first.
Meeting availability and booking
A user's weekly hours and non-working days determine when they appear free for meetings and when others can book time with them. If a team member works shortened Fridays or is out on leave, colleagues may still see open slots unless the calendar is set for that person. Confirm in a pilot how availability is shown to other users and whether team-level calendars feed into it.
Task due dates and deadlines
Whether a due date falls on a working day affects how overdue status and reminders should be read. A task due on a public holiday can appear overdue the next morning even though the team could not have acted on it. Ask the vendor whether due-date logic in your workflows and formulas respects the calendar, or whether you need to write that logic yourself.
Reporting on working days
Reports that compare activity per day, such as calls logged or leads contacted, can understate or overstate performance when non-working days are counted as zero or treated as normal days. Define with stakeholders whether metrics are per working day or per calendar day, then test one report against a known holiday week before rolling it out.
Ownership handoffs during leave
When an owner goes on leave, open cases and opportunities need a clear cover plan, and a calendar entry alone does not reassign records. Decide who receives follow-up work, how the handoff is recorded, and whether assignment rules or workflows should react to a user's non-working period. Verify these steps in a pilot with a real leave request.
Team calendars across regions
Teams spread across countries or sites observe different public holidays, so a single organization-wide calendar may not fit everyone. Confirm how team calendars interact with user-level settings when a person belongs to more than one team, and which calendar wins when they conflict. Document the precedence rule before entering holidays for the year.
Maintaining holiday data
Holiday and exception entries must be kept current each year, and missing entries will quietly distort availability and reports. Assign an owner for updates, decide how regional holiday changes are communicated, and check that imported or migrated users keep their calendar assignments after any data move.
Access and data considerations for leave and absence records
Working time calendars hold leave and absence dates, which are personal data about named people. The cards below cover who may change those records, how changes are traced, and how calendars stay aligned with identity and team membership when sign-in is centralized.
Who may edit calendars and exceptions
Decide which roles can change weekly schedules, team calendars and working or non-working exceptions before users are onboarded. A user should normally be able to see their own calendar, a team lead should manage their team's entries, and only a small administrator group should change organization-wide closures. Check the role permissions for each calendar scope in a test instance with real role combinations, not only the administrator account. Avoid giving daily users admin rights just to fix a holiday entry.
Leave dates as personal data
A record showing that a named employee is on sick leave or parental leave reveals information about that person's health or family life, so it deserves stricter handling than a public holiday. Limit who can read individual absence entries and keep them out of broad team views where possible. Confirm with your privacy team which entries are needed for scheduling and which should be recorded only as a generic unavailability.
Audit and change tracking
Scheduling decisions can depend on calendar entries, so you need to know who changed a working day, when, and from which value. Confirm in your EspoCRM version whether the stream or change history shows calendar and exception edits for the entity types you use. If it does not, document a manual review step for changes to organization-wide closures and export the calendar data on a schedule.
Aligning calendars with SSO and teams
When sign-in runs through OpenID Connect, team membership may be mapped from identity provider groups, so a person moved to another group can gain or lose the team calendar they should see. Decide whether the identity provider or EspoCRM is the source of truth for team membership, and test a leaver and a transfer case end to end. Calendar exceptions that belong to a team should be reviewed when membership changes, not left to drift.
Deprovisioning and retained entries
When an employee leaves, their user record may be deactivated, but past leave entries and their calendar links remain. Decide how long absence records are kept, who approves deletion, and whether the person's entries are anonymized. Check the deactivation behavior in a test instance so that a deactivated user does not keep appearing in team scheduling views.
Questions teams ask before configuring working time calendars
How much does it cost to set up working time calendars in EspoCRM?
No fixed price applies to this work because the cost comes from the scope agreed in writing, not from the feature itself. Working time calendars are a configuration area inside EspoCRM, so the main cost is labor: someone must define weekly hours, holiday lists and leave rules, then test them against real scheduling. Any licence cost depends on your deployment. The open-source edition can be self-hosted for free, according to the EspoCRM pricing page, while EspoCRM Cloud is priced per user per month, with the Advanced Pack included in all cloud plans. Ask for a quote that separates one-time configuration from any recurring updates to holiday lists each year.
How long does it take to configure working time calendars?
The duration depends on how many calendars you need and how much of the data already exists. A single organization-wide calendar with one holiday list is a small task, while separate calendars for several teams, regions and leave rules take longer to define and check. No researched duration is available for this work, so ask the implementation partner or your internal team to estimate it from your own list of teams, locations and holiday rules. Plan time for reviewing scheduling results with a few real users, because mistakes in working hours usually appear only when meetings or tasks are checked against them.
What data do we need to provide before configuring working time calendars?
Gather three inputs before any configuration starts: the standard weekly working hours for each group, the official holiday lists for each country or site, and the team structure that determines who follows which calendar. HR leave data is useful when you want individual absences, such as approved leave periods, to affect scheduling. Confirm who owns each input, since HR, operations and team leads often hold different parts of the picture. Clear inputs reduce rework, because each change to a team or calendar otherwise has to be retested.
Can an internal administrator set up working time calendars without a partner?
Yes, in most organizations a trained EspoCRM administrator can configure working time calendars with the admin interface, provided the rules are clear and the team has access to test accounts. The work is mostly data entry and verification rather than custom development. A partner becomes more useful when the rules are complex, such as several countries, shift patterns, or calendars that must match integrated systems. Whoever takes the work should document the calendar design, so later changes to holidays or team membership do not depend on one person.
What makes working time calendar setup take more effort?
Effort rises with the number of distinct calendars, the number of countries or sites with different public holidays, and the number of exceptions that apply to individuals rather than teams. Shift patterns, part-time schedules and approved leave that changes often add ongoing maintenance. Integration with other systems, or a need to reflect calendars in reports and automation, adds design and testing work. Effort falls when you agree on a small set of standard calendars and assign users to them rather than configuring each person separately.
Do working time calendars need the Advanced Pack or a cloud plan?
Confirm this against the current EspoCRM documentation for your version before you commit to a plan, because the feature set depends on the edition you run. The working time calendar documentation describes weekly schedules and working and non-working exceptions for users, teams and the whole organization, as of version 7.3. The EspoCRM Advanced Pack provides reports and workflows, which are the usual next step when calendars must drive automation. If you use EspoCRM Cloud, the Advanced Pack is included in every plan, so the question becomes which user tier fits your headcount.
What should we ask a partner to confirm in a quote for this work?
Ask for a written scope that lists each calendar, the teams or users assigned to it, the holiday sources used, and the exceptions that will be configured. Request a clear split between setup work and any ongoing maintenance, such as yearly holiday updates. Confirm what testing is included, who checks scheduling results, and how changes after go-live are handled. A quote should also state which EspoCRM version and edition the work targets, since behavior can differ between releases.
Official EspoCRM documentation on working time calendars
Start with the official EspoCRM working time calendar user guide before you configure anything. The guide describes the feature as it is documented for the EspoCRM version it was written against, and the calendar model is the part most likely to differ between releases. The supplied documentation states that working time calendars, as of v7.3, define weekly schedules with per-weekday hours and working and non-working day exceptions for users, teams and the whole organization. Confirm that your running version includes these options, and check the screens against your own instance, because menu labels, field names and where the calendar is attached can change.
Read the documentation with three questions in hand: which calendar applies to a user when a team calendar and the organization calendar both exist, how a non-working exception interacts with a weekly schedule that already marks that day as off, and which parts of EspoCRM consume the calendar. Scheduling, reminders and any custom logic that reads working hours are different consumers, so confirm the behavior of each one in a test instance rather than assuming the calendar is applied everywhere. Record the answers in your deployment notes, since they determine whether you need one calendar or several.
If your version of the guide does not match what you see, or the documentation is silent on a point your business depends on, ask the vendor or test it on a staging copy of your instance. Keep the EspoCRM version, the calendar settings and the test results together, so that a later upgrade can be checked against the same cases. Any scope agreed with a partner should name the version the calendar design was validated on.
How DeployOpen scopes and delivers EspoCRM calendar configuration
DeployOpen plans and configures EspoCRM working time calendars as part of a wider CRM build, starting from how your teams actually work and where they are located. We scope the calendar rules in writing, build and test them in your own instance, and hand over a documented setup your administrators can maintain.
How we scope
- We list the users, teams and locations whose working hours and holidays need to be represented in EspoCRM.
- We agree in writing which weekly schedules, non-working days and leave exceptions the calendars must hold.
- We confirm which scheduling views and records depend on calendar data, so testing covers the features that rely on it.
- Engagements are fixed-scope, so the written scope sets deliverables and timelines before any configuration starts.
How we build
- We configure the organization calendar, team calendars and user-level exceptions in your own EspoCRM environment.
- We test sample scheduling cases, including public holidays, partial days and leave, and record the results.
- We check that calendar settings behave as expected for users in different teams and time zones your organization uses.
- We confirm the configuration against the scope before handover, and log any gaps for agreed follow-up.
How we hand over
- We provide written documentation of each calendar, its owners, its holidays and the rules for updating them.
- We walk your administrators through adding exceptions, reviewing team calendars and checking how they affect scheduling.
- We record the configuration decisions so future changes, such as a new team or a new country, follow the same logic.
- We agree a handover checklist that your team signs off, so ownership of the calendar data is clear.
How we support
- Ongoing support, upgrades and reviews are available as a retainer, covering calendar changes after go-live.
- We can review calendar settings again when EspoCRM is upgraded, so holidays and schedules stay correct.
- Yearly holiday updates and staff changes can be handled under the retainer or a separately scoped change.
- Ask us to confirm which support terms apply to your environment before the written scope is signed.
