Integrations overview

Integrations bring live information into a dotBlast dashboard. Start with the smallest set of integrations that supports the screen’s purpose, then expand after the dashboard is running reliably.

Target audience: workspace admins, dashboard builders, and operations teams connecting external data to shared displays. Goal: explain the supported integration categories and route users to the right setup or troubleshooting article. Key assumption: the dashboard structure exists or will be created before integrations are connected.

<screenshot: dotBlast integrations page showing calendar, weather, and iframe options>

Supported integration categories

The first public docs set should cover three core integration paths:

Calendar: show schedules, room bookings, events, or team availability.
Weather: show local conditions and forecasts for the display location.
Iframe proxy: embed approved web pages or internal tools that need to appear inside a dashboard.

Each integration solves a different content problem. Calendar is best for time-based context. Weather is best for location-aware public or office displays. Iframe proxy is best when the content already exists somewhere else and dotBlast needs to display it cleanly.

Calendar integrations

Use a calendar widget when the dashboard needs to show what is happening today or what is coming next. Common examples include conference room schedules, office event displays, shift calendars, release schedules, and visitor-facing agendas.

Before connecting a calendar, decide which calendar the screen should show. A shared display should usually use a shared calendar, not an employee’s personal calendar. This keeps permissions easier to reason about and avoids exposing private events.

After connecting the calendar, check the display view. Confirm event titles, times, and empty states look right. If the dashboard is public, review whether event details should be visible. Some teams use separate display calendars with simplified event titles so the screen stays useful without exposing private notes.

<screenshot: calendar widget configured with today’s events>

Typical calendar setup flow:

Add a calendar widget to the dashboard.
Choose or connect the calendar source.
Select the calendar to display.
Confirm timezone and event range.
Preview the dashboard on the target screen.

If events do not appear, check account permissions, calendar selection, timezone, and whether the source calendar has events in the displayed range. If sign-in or magic link access fails, use the authentication troubleshooting article from the troubleshooting decision tree.

Weather integration

Use a weather widget when the display is tied to a physical location. Lobby screens, office dashboards, school displays, and retail back-office screens often benefit from local weather because people use the screen before leaving, commuting, or planning the day.

Weather setup should be simple: choose the location, confirm units, and place the widget where it supports the rest of the dashboard. Do not let weather dominate the layout unless the screen’s main job is local operations.

<screenshot: weather widget settings with location and units>

Good weather widget placements:

Lobby dashboard: near the daily agenda or welcome message.
Office dashboard: beside calendar and announcements.
Operations dashboard: smaller supporting widget near shift or route context.

If the weather location is wrong, check whether the widget uses a city, postal code, or saved location setting. If the widget is blank, confirm network access and reload the dashboard. If it still fails, capture the screen state and include the dashboard name, configured location, and device type in a support request.

Iframe proxy

Use iframe proxy when an existing web page needs to appear inside a dotBlast dashboard. This can include internal status pages, analytics views, public reports, queue displays, or lightweight operational tools.

Iframe content is powerful, but it is also the most likely integration to need troubleshooting. Many websites block embedding for security reasons. Some require authentication. Others render poorly at TV sizes or refresh in ways that do not work well for unattended displays.

<screenshot: iframe widget showing a configured URL and preview>

Before adding iframe content to a production screen, test the exact URL in preview and on the target display. Check three things:

Does the page render inside the widget?
Is the content readable from the expected viewing distance?
Does it stay current without someone interacting with it?

If the iframe is blank, do not assume the dashboard is broken. The source site may be blocking embedding. Use the iframe troubleshooting article to check headers, authentication, allowed domains, and proxy behavior. If the page requires a personal login session, consider whether it is appropriate for a shared screen.

Choosing integration scope

For a first dashboard, connect one integration at a time. Add the calendar, preview it, then add weather, preview it, then test iframe content. This makes setup problems easier to isolate.

Avoid building a dashboard where every widget depends on a different external service. If several integrations fail at once, the screen may become useless. A strong shared dashboard usually mixes live content with stable content, such as announcements, static instructions, or a simple status message.

Privacy and permissions

Shared screens are public within their physical environment. Treat anything displayed there as visible to visitors, contractors, and anyone walking by. Before connecting integrations, review whether event names, embedded pages, or internal metrics should be shown in that location.

Use shared service accounts or shared calendars where appropriate. Keep ownership clear so a dashboard does not break when one employee changes roles, loses access, or leaves the company.

Recommended next action

Start with the integration that most directly supports the dashboard’s job. If the screen is schedule-driven, connect calendar first. If the screen is location-driven, add weather. If the screen depends on an existing web page, test iframe proxy early and use the troubleshooting decision tree if it renders blank.