Module 2: Access rules for cardholders and doors
How Synergis decides who gets in, where to attach rules, and advanced restrictions like antipassback and threat levels.
- Understand how Synergis decides who gets in
- Know where to attach rules (groups, areas, doors, elevators)
- Use temporary rules, unlock schedules, two-person, escort, antipassback and threat levels without creating a mess
2.1 The three W's of a Synergis access rule
Synergis uses access rules, not the access levels or clearance codes found in many other systems. An access rule answers who (cardholders and cardholder groups), what (grant or deny) and when (a schedule). The rule is then attached to doors, areas or elevators.
When a card is lost, you give the cardholder a new credential and every rule still applies, with no change pushed to the rules on the controllers.
2.2 How competing rules are resolved
Two rules decide every conflict: when no rule applies, access is denied, and when rules conflict at the same moment, deny wins. Genetec's own example for a cardholder named John at Door A:
| Rule | Effect |
|---|---|
| Rule 1 | Grant, weekdays 9:00–12:00 and 13:00–17:00 |
| Rule 2 | Grant, Wednesdays 10:00–13:00 |
| Rule 3 | Deny, Fridays 16:00–17:00 |
| John badges at | Result | Why |
|---|---|---|
| Monday 9:15 | Granted | Rule 1 |
| Tuesday 12:30 | Denied | No rule applies |
| Wednesday 12:30 | Granted | Rule 2 |
| Friday 16:15 | Denied | Rule 3 deny overrides Rule 1 |
Genetec's guidance: grant with schedules and let inactive time be denied by default; use explicit deny rules only for exceptions.
2.3 Where to apply a rule
| Apply to | When | Example |
|---|---|---|
| Cardholder group | The default. People come and go; groups do not. | Add a new nurse to the Nursing - ICU group and they inherit every ICU rule. |
| Individual cardholder | Only as a temporary measure or a true exception. | A contractor needs the roof hatch this week (better: a temporary rule). |
| Area | A space with several perimeter doors that share the same policy. | Rules on the Data Center area apply to all its perimeter doors automatically. |
| Door | A single door with its own policy, or doors in one area that need different rules. | Loading dock door open to Shipping only. |
| Elevator | Per-floor access on a controlled elevator. | Floors 10–12 for Finance. |
Areas define perimeter doors (to enter and exit) and captive doors (inside the area). Correct door sides are what make people counting and antipassback work. A rule on an area applies to all perimeter doors even though it is not listed on each door's own rules page, which is a frequent source of "why does this person have access?" questions.
2.4 Temporary access rules
A temporary rule has an activation time and an expiration time and is deleted automatically seven days after it expires. Use it for semester students, project contractors, or a technician who needs a server room for two days.
- One cardholder: assign it from the Cardholder management task in Security Desk.
- Several cardholders or groups: edit the rule's properties in Config Tool.
- Synergis units honour temporary rules while offline; HID units need to stay connected with automatic synchronization.
- Activation happens on schedule; expiration takes effect after the unit synchronizes with the Access Manager.
2.5 Door behaviour: unlock schedules and first-person-in
An access rule controls who may badge in. An unlock schedule controls when a door is simply unlocked for everyone, for example a lobby from 8:00 to 18:00 on weekdays. Holiday schedules and exceptions belong in the schedule, not in extra rules.
The first-person-in rule keeps an unlock schedule, or other cardholders' access, from starting until a designated supervisor has badged into the area. It prevents a store front from unlocking on a snow day when nobody is there. Feature support depends on the controller (for example, HID units do not support it).
2.6 Two-person rule, visitor escort and antipassback
| Restriction | What it does | Typical use |
|---|---|---|
| Two-person rule | Two cardholders must present credentials within a set delay of each other. | Vaults, pharmacies, evidence rooms |
| Visitor escort | A visitor's badge works only when a host cardholder badges too. | Labs, data centres, visitor-heavy offices |
| Hard antipassback | Logs the violation and denies access. | Parking, high-security areas |
| Soft antipassback | Logs the violation but grants access. | Rolling out APB, collecting data first |
| Strict antipassback | Checked on both entry and exit; you cannot leave an area you never entered. | Mustering accuracy |
| Interlock (mantrap) | Only one perimeter door of the area can be open at a time. | Clean rooms, sally ports |
Antipassback needs entry and exit readers on every perimeter door, correct door sides, and a presence timeout so people who tailgate out do not get locked out forever. Turn it on only once doors, areas and schedules are stable. Support differs by hardware (for example on HID units interlock and antipassback cannot both be enabled on an area), so check the feature-support table for your controller.
2.7 Threat levels
A threat level is a predefined scenario, such as a lockdown, an evacuation or a VIP visit, that an operator activates for one area or the whole system. Activating it runs a set of actions (lock perimeter doors, override unlock schedules, set a minimum security clearance so only cleared cardholders get in, change camera behaviour), and deactivating it returns the system to normal. Build and test them before you need them, and note that some controllers do not enforce minimum security clearance (Mercury does not).
2.8 Least privilege best practices
- Name rules by intent: "Lab Technicians - Business Hours", never "Rule 7".
- Model groups on roles and locations, so a person's access is the sum of their roles.
- Prefer areas for shared policy and doors for exceptions.
- Use temporary rules instead of permanent ones you plan to remember to remove.
- Review high-risk areas quarterly (ClearID can delegate this to area owners).
- Use partitions so each site's admins manage only their own entities.
- Document every explicit deny rule; they are easy to forget and hard to troubleshoot.
Common mistakes
- Assigning rules directly to hundreds of individuals, so nobody can tell why a person has access.
- Forgetting that area rules flow to every perimeter door.
- Using an Always grant rule where an unlock schedule was intended, or the reverse.
- Enabling hard antipassback before door sides and exit readers are right, locking people out.
- Building a lockdown threat level and never testing it.
Check your understanding
1.What are the three W's of a Synergis access rule?
2.A cardholder has a grant rule and a deny rule active at the same time. What happens?
3.A new hire needs the same access as 40 colleagues. Where do you grant it?
4.What is the difference between an access rule and an unlock schedule?
5.Why are temporary rules better than adding someone to a group and removing them later?
6.Soft antipassback…
7.You put a rule on the Server Room area. Will it show on each perimeter door's access rules page?