Protected content

Login Get access

DT NOW - config

Audience: Door Tablet administrators, implementation partners and support teams.

1. What Door Tablet NOW does

Door Tablet NOW opens a room-specific workplace interface in a phone browser when a user scans a Door Tablet QR code. It combines room status, the daily schedule, room facilities and permitted meeting actions. Users can identify themselves, reserve an available room, check in to eligible meetings, extend a meeting or release it early, subject to the calendar integration, their identity and the organisation’s settings.

NOW complements both interactive room displays and Door Tablet EPS ePaper displays. The phone provides the interactive interface; the display provides the room context and QR code. The phone needs access to the Door Tablet web server and any applicable identity email. Scanning a QR code does not establish a Bluetooth connection to the display.

2. Components and prerequisites

• A working Door Tablet server, configured resource and supported calendar connection.
• A QR-capable display configuration, with the display/resource licensed or running under the applicable evaluation policy.
• A phone browser able to reach the published server address. Use HTTPS with a certificate trusted by the phone. Internal-only deployments require the appropriate network access.
• Working outgoing email and correct user email addresses for verification and notifications.
• Consistent server, calendar and device time settings. Keep the server clock synchronised.
• Current matching HTML, JavaScript, stylesheets and server code. Updating one component alone may leave controls incompatible.

3. Enable the QR entry point

1. Open the System Profile and the EPS, QR Codes, Meeting Processing, Display, Futures, Master/Slaves section.
2. Under QR code handling, enable Show QR Codes.
3. Set Server name only when phones must use a different published host. The field expects a host name; otherwise the current server is used. Confirm the resulting QR URL is reachable from the phone’s network.
4. Choose Void after and, if required, Show on Nearby.
5. Review each resource’s Basic QR value. A supplied value replaces the generated NOW destination. Leave it empty when you want the standard generated NOW link. A custom QR may deliberately open another service.
6. Refresh the room displays. Scan the actual displayed QR code on a phone and confirm it opens the correct room.

4. Choose the operational mode

5. Users, domains and identity controls

For automatic user creation, enter complete domains under Domains, preferably one per line, for example example.com. Matching is exact: add a subdomain separately when it should be allowed. At least one domain is required when automatic creation is enabled. Existing users are reused. A new standard user is created only after successful email validation; creating that record does not automatically authorise a PIN or administrative access.

The domain list controls automatic creation. Do not describe it as a universal sign-in allowlist: existing users are unaffected by that creation filter, and disabling automatic creation does not by itself prohibit the verified-email journey.

Use Disable DT NOW Access on a user to block new verification and continued use of a saved identity. Successfully verified registered users are marked mobile-enabled in the Users list. Keep email addresses unique and current. Failed or ambiguous lookups must be corrected rather than worked around by issuing shared identities.

Verification challenges currently expire after ten minutes and limit failed attempts. PIN and non-PIN journeys both depend on email delivery. Keep browser cookies and website storage available during verification. The mobile verification flow is separate from the application/database login that may protect the form itself.

6. Reservation and meeting policy

• Reserve: offered when the resource allows ad-hoc reservations, the room is available, sufficient time remains and the verified identity has permission. Users select a duration and participant count in the reservation panel. The former separate 30-minute and one-hour quick buttons are not part of the current interface.
• Duration choices: follow configured slots and the available interval. Maximum booking length, the next meeting and local midnight can restrict the choice. The server rechecks availability before saving.
• Check in: depends on room check-in policy, the check-in window and identity rights. The intended current rule excludes the creator of their own ad-hoc meeting from an unnecessary check-in prompt; an organised future meeting may still require check-in.
• Extend: offered to an eligible owner when meeting controls allow it and enough time remains before the next booking. The current rules permit one extension. Do not promise unlimited or repeated extension.
• Terminate/release: permits early release when the user and room policy allow it. Allow release of all bookings permits eligible verified users who checked in to release calendar meetings when room release is enabled. The grace period still applies unless instant termination is enabled. It does not allow arbitrary users to cancel every booking.
• Creator exception: an authorised creator can release their own NOW reservation immediately, subject to the meeting remaining active and editable.
• Privacy: room and calendar privacy rules can mask meeting details. A hidden subject does not mean the slot is free.

7. Language and terminology

Under Door Tablet NOW, select Language or leave From the resource. Users can select another language from the mobile interface; a supported saved browser preference takes precedence on later visits. If no supported preference/default can be selected, English is the fallback.

The current language selector includes Arabic, German, English, Spanish, Finnish, Filipino, French, Hebrew, Hindi, Italian, Japanese, Korean, Lithuanian, Malay, Dutch, Polish, Portuguese, Romanian, Russian, Slovak, Serbian, Swedish, Thai, Turkish, Vietnamese, Simplified Chinese and Traditional Chinese. Translation coverage and custom terminology should be reviewed in the languages you publish.

Select an optional Translation set to adapt supported text. It applies when its language matches the selected language; otherwise the corresponding resource/default language text is used. Check right-to-left layout, long labels, error messages and verification emails as well as the main screen.

8. Branding

Set CSS file path to an accessible CSS URL, web path or the name of a CSS attachment on the System Profile. The value must end in .css. The custom stylesheet is loaded after the standard styling. For a small change, use Or inline styles; inline styles are applied only when no CSS file path is supplied.

Example inline rules:

.resource-card { border-top: 4px solid #005a70; }
#reserve-now { background-color: #005a70 !important; }

Use absolute image URLs in deployed branding when assets live in another database. URLs inside an external CSS file resolve relative to that stylesheet. Test every asset from the phone network. Preserve readable contrast, focus indicators, error text and touch targets. Licensing/evaluation notices are product controls and are not a branding surface.

9. QR expiry, identity and licensing are separate

10. EPS and static displays

Enable Enable EPS when deploying Door Tablet EPS and configure the ePaper resources through the normal EPS workflow. Make sure the chosen display layout includes the room’s QR code. NOW adds phone-based interaction without requiring the ePaper panel to become a touchscreen. A change made in NOW reaches the scheduling system; the physical EPS image then follows the configured EPS update process. Do not promise that the ePaper image updates at the same instant as the phone.

Test scan distance, QR size and contrast at the installed location. Keep the QR tied to the correct resource. A copied link can be opened elsewhere; use network, identity and room-action policy for access control rather than assuming the scan proves proximity.

11. Deployment and acceptance

1. Deploy the form and included HTML in the application database, and matching JavaScript, CSS, images and Java/XPages code in the web UI database. In this project, those are the separate DoorsODP and DoorTabletODP projects.
2. Update m.js, mconstants.js and affected stylesheet/HTML cache references together. Regenerate compressed siblings for served development assets.
3. Check the database resource contents and the files actually served over HTTP. A completed sync operation alone does not prove that a file resource changed.
4. Test PIN and email identity, forgotten PIN, user blocking, automatic creation with allowed/disallowed domains, language choice and branding.
5. Test reserve, competing bookings, check-in, extension and release for each deployed calendar backend. Test release again immediately after an extension, before reloading.
6. Test QR expiry separately from evaluation/licence notices, and verify EPS/static codes remain usable under the intended expiry policy.
7. Test on the supported phones and networks. Recheck private meeting masking, unavailable actions, delayed email and network interruptions.