Why Microsoft 365, and how the metaphor maps to the platform

Chapter 1. Background

The integration of technology in emergency management is the fastest growing and evolving component of the profession. Daily technological advancements, as well as emergency managers’ ever-increasing dependency on technology to manage incidents, create new issues to overcome. With all the options available to the modern-day emergency manager, it is easy to get overwhelmed in determining which is the best program to use. We believe the primary goal of any system is to make a process as efficient as possible.

The number one reported issue in every after-action report is a lack of communication. Technology can help bridge that gap. This project, lovingly named "Our House," gives every level of emergency management a common operating picture -- not just during an incident but through all phases of emergency management.

The metaphor

Imagine you are building a house.

• Building site -- Microsoft 365. Open communication requires a common language, and nearly everyone across multiple industries already uses the Microsoft platform.

• Foundation -- SharePoint. The organizational base everything sits on: sites, lists, and document libraries.

• Rooms -- Channels. In SharePoint they look like folders; in Teams they look like channels. Rooms organize the living space.

• Windows -- Microsoft Teams. The primary way stakeholders look into and interact with the house.

• Frame -- Power Automate. Connects the rooms together and passes information between them.

• Roof -- Chat and conferencing. Connects the users to one another.

• Furniture -- the tabs. Power BI, Power Apps, Lists, Planner, Tasks, ArcGIS, and more. Every room has standard furniture, plus custom pieces to fit your agency’s needs.

What you can build

Processes this guide demonstrates, all on the same platform: project management, task management, grant management, weekly reports, approval requests, meeting tracking, special event tracking, public education tracking, exercise scheduling and reporting, employee information management, org chart management, performance metrics, stakeholder engagement, vehicle usage management, incident reporting, travel status tracking, incident tracking and SITREPs, a common operating picture, and after-action reports.

Chapter 2. Create the Team

Everything starts with one Team. Its channels become the rooms, its SharePoint site becomes the foundation, and its tabs become the furniture.

Walkthrough: create the Team

1. In Microsoft Teams, select "Join or create a team," then "Create team."

2. Choose the Staff team type. Staff leaders are owners; everyone else joins as members.

3. Enter the team name (for example, "Office of Emergency Management") and an optional description.

4. Set Privacy to Private so only team owners can add members.

5. Click Next, then add employees and stakeholders. You can also add people outside your organization as guests by typing their email addresses.

6. Click Add, then Close. The team is created with a General channel.

// NOTE You can also create a team using an existing team as a template. Once your first Our House build is stable, templating is the fastest way to stand up a second one.

Chapter 3. Rooms (Channels)

Rooms are how the house is organized. Every team is organized differently -- build rooms around how your organization actually works.

Standard rooms

• General. Every team comes with a General channel. Use it as the Admin room: group-level information and historical records.

• Training and Resources. Knowledge checks, certificates, and reference material for the team.

• One room per incident. Create a channel for each incident the team responds to, named with the incident number (for example, "R26-03 Winter Storm"). Chapter 17 shows how automation keys off this naming.

Custom rooms

At a state level, a district team might use one channel per county, because a person is assigned to every county and records are created specific to each. At a local level, a department might create a channel per section -- Preparedness & Resilience, Mitigation, Response & Recovery -- or per EOC position: Operations, Planning, Logistics, Finance. Give external partners their own channels too, so they have one place to post updates and pull files instead of everything running through email.

Other rooms your team may want: Weekly Reports, Weather Monitoring, EMAP Accreditation, COOP Plan, Emergency Operations Plan, Logistics, Fleet, Grants.

FIG 01 // Example room layout for a local department. Orange = channels; shaded = representative tabs and sub-rooms.

Walkthrough: add a channel

1. Select the three dots next to the team name and choose "Add channel."

2. Name the channel for the room it represents. Keep names short and durable -- automation will reference them.

3. Set privacy (Standard for most rooms; Private for sensitive rooms such as grants).

4. Repeat for each room in your layout. Use the same tab set in every room of the same type -- consistency is what makes the house navigable.

Chapter 4. Furniture: the Standard Tabs

A dining room isn’t complete without a dining table, but you wouldn’t put a dining table in a bedroom. Same with channels. Standard furniture appears in every room; custom pieces -- Dashboard, Calendar, Contact List, Tracker, Projects, Map Atlas, Outage Maps, Reports, Asset Tracking, Inventory Tracking -- go where they are used.

Posts

The Posts tab is the running log of events in the room. In the Admin room, think of it as the 30,000-foot view of daily and weekly happenings and due-outs. Power Automate should route notifications from the other rooms here -- important notices about incidents, trainings, meetings, and reports -- so leadership can watch one feed.

FIG 02 // Posts tab as a running log, with Power Automate posting automated notices alongside human conversation.

Walkthrough: create a task from a post

1. Select the three dots on the right of any post.

2. Select "More actions."

3. Select "Create task."

4. In the dialog, rename the task, confirm it is created in the correct plan, assign a priority, bucket, and team member, then click "Add task."

Tasks created from posts link the information in the post to an action item -- key for tracking unmet needs and for coverage and succession planning.

Files

The Files tab creates a separate file repository for items related to the specific room. Storing files in Teams lets members work collaboratively on the same files and eliminates version issues. When setting up a channel, use the same folder structure in every room of the same type. For related reference files -- job aids, resources -- consider a SharePoint list instead of a folder so items can carry metadata.

Dashboard

A dashboard provides a central location for all forms pertinent to agency operations and reporting. Inputs on each form route to the applicable rooms and the agency SITREP through Power Automate. Dashboards can be built in either Power Apps or Power BI: Power Apps when the dashboard is a launchpad of forms and actions, Power BI when it is jurisdictional data -- FIPS number, UEI number, PA thresholds, population, area, mutual aid partners, open project data, industries, past disaster declarations -- filtered interactively.

FIG 03 // A Power Apps dashboard used as the front door for daily operations, incident reporting, and incident tracking.

Projects

The Projects tab is built on a SharePoint list using a Microsoft-provided template. It tracks all projects for the room, lets you categorize projects to create metrics (such as the phases of EM), and gives each project comments for progress logging, conversations for bigger issues, task assignment, and attachments -- which provides continuity when the assigned employee is on leave.

Walkthrough: set up the Projects tab

1. Select the plus button at the top of the channel to add a tab.

2. Search for "Lists," select Lists, and click Save.

3. Select "Create a list."

4. Select "Work progress tracker" from the templates and click "Use template."

5. Rename the list "Projects." You will use this same list across all channels and create dynamic views per channel using the category column.

6. Select Create.

FIG 04 // Adding the Projects list as a tab: the numbered sequence from the tab picker to the template gallery.

Custom views in Lists

For large data sets -- including the single shared Projects list -- create views that filter automatically, so each room’s tab shows only its own rows.

1. In the list, click "All items," then "Create new view."

2. Name the view and click Create.

3. Open your view from the tab bar next to All items, then click "Edit current view."

4. Add filters (for example, Category equals this room’s name) and click OK.

5. When sharing the view or adding it as a Teams tab, make sure the view is selected first, then copy the URL -- the URL encodes the view.

Tasks (Planner)

Tasks are managed by Microsoft Planner. Each plan tracks the tasks for one room, divided into user-defined buckets -- To Do, Projects, Employee Onboarding, Employee Training, Public Education. Planner’s prebuilt graphic and calendar views help management see assignments at a glance.

1. Select the plus button to add a tab and search for "Planner."

2. Select Planner, create a new plan, and name it "Tasks (Channel Name)" -- the channel name suffix keeps plans distinguishable in rollups.

3. Select Save.

4. Add buckets that match how the room works, and set task labels for quick filtering.

Employees can see every task assigned to them on one page -- regardless of team or channel -- from the Planner icon in the Teams left-side menu.

FIG 05 // The employee task view: one page for every assignment across all plans.

Atlas

If your agency uses ArcGIS, work with your GIS department to develop a map atlas tab containing layers of CI/KR data useful for incident planning. For example, draw a polygon over an impacted area to get a list of the businesses, houses, and population inside it. Useful layer families include critical infrastructure (power plants, stations, EOC locations, schools, transmission lines, water districts, gas and sewer lines), care facilities of all types, day cares, venues, fatality-management resources, unemployment by ZIP, medically underserved areas, and the FEMA National Risk Index.

Incident-specific tabs and reference material

The list of tabs you can add is endless. Add tabs that give quick information specific to the incident: a power outage tracker, a burn ban map, the NIMS IAP, active wildfire maps, an NWS chat. Keep a Reference Material tab (a list, organized by category and color-coded) as the central place for department knowledge -- guides, contact lists, and other resources.

// PART II //

Information, assets, vehicles, weekly reports, and approvals

Chapter 5. Employee Information Management

Employee data goes stale fast when it lives in three different spreadsheets that all claim to be current. Start with a form that gathers the employee data you need on a standard template: name, title, hire date, business cell, business email, vehicle data (if assigned), radio data (if assigned). The collected data feeds a dashboard with all employee information for quick reference -- and can drive a dynamic organization chart that never goes stale.

Chapter 6. Pool Vehicle Management

If your department shares vehicles or other resources, track usage requests in Our House.

How it fits together

• The app. Power Apps displays the reservations Excel table (MS Forms stores submissions in Excel). An employee checks whether the vehicle is reserved for the day.

• The form. If free, the employee clicks "New reservation" and is directed to the form: pick-up date, return date, destination/reason (meeting title or incident number), and vehicle (a choice list of pool vehicle numbers).

Chapter 7. Equipment and Inventory Tracking

Your EOC may have computers, EMS might have AEDs, IT could have iPads -- equipment available for checkout for trainings or activations. Our House manages the inventory with a form, a flow, and a list.

EMPLOYEE COMPLETES FORM → POWER AUTOMATE UPDATES INVENTORY → HISTORY LOGGED

The checkout form

Put a QR code on each device linking to the checkout form. Fields: Status (select "In use" if checking out, "Available" if returning), Expected return date (shown only when "In use" is selected), and Device number (multi-select as needed).

The inventory list

Inventory is managed in a SharePoint list. Example columns: device photo, checked-out date (autofilled), expected return date (autofilled), inventory control number (issued by IT), grant inventory number (if grant-purchased), expenditure name, asset type (preset options), and serial number.

// UPDATED PATHWAY In the current build, the checkout flow does two writes, not one. When the form is submitted, the flow updates the tracker list -- the person’s name and email if the status is "In use," otherwise just the status -- and then creates an item in a separate Checkout History list to record the change. The tracker answers "where is it now"; the history list answers "where has it been." Add the history list from day one; retrofitting an audit trail is much harder.

Chapter 8. Vehicle Tracking

If responders are issued vehicles, they may need to track mileage, fuel, and maintenance. This build lets a responder enter information from a smartphone and sends notifications when maintenance is due. The example uses Smartsheet; the same shape works in Lists.

• Fuel / maintenance form. Vehicle number, date, cost, odometer, vendor, work performed, and a photo of the receipt.

• Daily mileage. A dynamic view scoped per user shows only their assigned vehicles. The user opens the vehicle, finds the day-of-month box, and enters odometer mileage plus a summary of use. At month end, the system archives all submissions to a master sheet and resets the user sheets.

• Maintenance due. Service thresholds (for example, oil every 5,000 miles) are computed from the mileage log. When crossed, the flag turns red and an email goes to the assigned driver and their supervisor.

Chapter 9. Weekly Reports

Automating the weekly report keeps every week built the same way -- from defining the content, through collection and aggregation, to generation.

LEADERSHIP DEFINES METRICS → EMPLOYEES SUBMIT FORM → POSTS TO SECTION + GENERAL ROOMS → DATABASE UPDATED → SUPERVISOR REVIEWS AND SUBMITS TEAM REPORT → AUTO-FILLED WEEKLY REPORT → LEADERSHIP PRINTS

Start by identifying the specific categories of information or metrics to collect, and build the form for those inputs. All members fill the form weekly for their areas of responsibility; the supervisor reviews the entries and makes one collective submission for the team. Forms can be built in any form maker -- the two easiest options are MS Forms and Smartsheet. Use workflows to push the automatic messages: the section report auto-posts to each section room, and a submission notification posts to the General room so leadership can see at a glance who is in.

Chapter 10. Approval Requests

Vacation, sick, trainings, exercises, deployments, projects, purchasing -- all need supervisor approval. This process cuts the back-and-forth out of approvals and leaves a simple record of every decision. The workflow below assumes three levels of supervision; adjust to your structure.

EMPLOYEE SUBMITS REQUEST FORM → FLOW ANALYZES DATA → EMAIL TO SUPERVISOR → SUPERVISOR APPROVES/REJECTS → ESCALATES PER LEVEL → EMPLOYEE NOTIFIED → RECORD LOGGED

Walkthrough: acting on a pending approval

1. Read the request description in the Approvals app.

2. Click to view any attachments.

3. Click the comment section to add any applicable comments.

4. Click Approve or Reject. The flow emails the requester and the next level automatically.

FIG 06 // The approval review screen: description, attachments, comments, and the approve/reject decision.

Every decision lands in the Approvals record -- a personnel-level history of requests, sources, dates, senders, and outcomes -- which doubles as your audit trail.

// PART III //

Continuity planning, accountability, and public education

Chapter 11. Continuity of Operations (COOP)

Emergency management is often the entity responsible for creating and maintaining a variety of plans. This chapter shows how to manage input from all departments in the jurisdiction to keep COOP/COG plans current using Our House. The same shape works for any plan type.

DEPARTMENT REP UPDATES TABLES → EMAIL NOTIFICATION TO OEM → TEAMS UPDATES ANNEX + BASE PLAN → POWER BI DASHBOARD REFRESHES

Data entry

Three Excel tables feed the COOP plan: COOP POCs, Essential Functions, and Continuity Locations. By giving department personnel direct access to these tables, the responsibility for accuracy shifts onto each department -- where it belongs.

// UPDATED PATHWAY Keep the Excel tables as the single live source. In an early build, parallel SharePoint lists were created for Essential Functions and continuity addresses; over time the lists went stale while the .xlsx files stayed current, and a dashboard query quietly kept reading a stale list. The reconciled pathway: the .xlsx tables are canonical, Power BI and Power Apps read only the tables, and any duplicate list is retired. If you ever find a list and a file with nearly the same name, treat it as a defect and pick one.

Dashboard

The Excel tables are linked to the annex in Word and to a Power BI dashboard. The EOC selects a department and division, which populates continuity locations, essential functions, rally points, and orders of succession -- no digging through individual annexes. The ArcGIS integration with Power BI can plot continuity locations geographically to ensure multiple departments are not claiming the same site.

NIMS compliance

Part of COOP planning is ensuring all POCs listed in the plan are NIMS compliant. Build a SharePoint list where each employee is an item; create a dynamic view per department so each sees only its own people. In this example IS-100, 200, 700, 800, and 2200 are required and G-300/400 optional. A calculated column flips "NIMS Compliant" to Yes when all required course columns are Yes (the formula is in Chapter 28), which triggers a verification email to OEM.

// UPDATED PATHWAY The current build adds a rollup on top of the per-person tracking: whenever the compliance list is modified, a flow counts the number of NIMS-compliant employees and the percentage of total employees for each department, then writes those totals to the COOP list -- so the dashboard always shows department-level compliance without a manual tally. A second flow emails OEM whenever compliance changes, attachments are added, or a certificate is issued.

Chapter 12. Travel Status and Personnel Accountability (PAR)

Keeping accountability of employees during incidents and travel is critical for responder safety. Our House uses workflows and Power BI to track employee status and display critical location information.

STAFF TAPS WIDGET ON PHONE → SELECTS STATUS, SUBMITS → FLOW UPDATES STAFF DATABASE → POWER BI UPDATES REPORT → SUPERVISOR VIEWS IN TEAMS OR APP

Through an instant flow built from the Power Automate app, the employee selects Enroute, Arrived, Clear, or PAR. For travel, the employee advances the status as the trip progresses. When an accountability report becomes necessary, all employees select PAR. The recorded status, joined with real-time location data, feeds a Power BI dashboard supervisors watch during an event.

FIG 07 // The PAR dashboard: current status of all employees during an event.

Chapter 13. Public Education Tracking

Public outreach and education -- flyers, presentations, giveaways -- deserves the same rigor as response. This build tracks both the inventory you hand out and the events where you hand it out.

OEM COMPLETES BAG COUNT FORM → FLOW UPDATES ITEM COUNTS → AFTER EVENTS: PUB ED REPORT → FLOW POSTS REPORT TO ROOM → POWER BI UPDATES → FLOW DECREMENTS INVENTORY

The inventory list

Public education inventory lives in a SharePoint list. Example columns: photo, serial number (an external agency number, such as a FEMA flyer number -- useful for reorder), description, quantity on hand, source, asset type (giveaway, prize, flyer, bag), reorder point (for notifications), ID (auto number), and bag (which set the item belongs to).

Bags and the two forms

In this example the office hands out prepared bags rather than individual items -- Adult English, Adult Spanish, Child English, Child Spanish, Senior English -- identical giveaways, audience-specific flyers. Two forms keep the counts true:

• Bag count form (inventory update). Used when bags are prepared. The flow increases the bag count in inventory and reduces the component item counts by the number of bags built.

• Public education report. Filed after each event: event date, meeting title, detailed description, core topics, age group, number of each bag kind handed out, method of communication (in person prompts for an address, for mapping), and file upload for photos. The flow subtracts the bags handed out from inventory by category, then posts the report to the preparedness room.

// PART IV //

From a starter flow to a production outage-monitoring pipeline

Chapter 14. The Mission and the Mandate

You may have a list of people with statuses you need to track -- in our case, a vulnerable population registry -- whom you must contact in an emergency such as an extended power outage.

In Texas, that registry is STEAR: the State of Texas Emergency Assistance Registry, a free state registry that provides local emergency management planners and responders with information related to a registrant’s needs during an emergency. Registrants include people with disabilities, people who are medically fragile, and people with access and functional needs. Registration is voluntary, must be renewed annually, and does not guarantee assistance -- a point worth repeating in every piece of public messaging.

The legal driver

Texas Government Code Chapter 418 makes wellness checks a statutory duty. Section 418.255 defines the triggering events: an extended power, water, or gas outage; a state of disaster declared under the chapter; or any other event considered necessary by the commission, the department, or the division. Section 418.256(c) sets the clock: a wellness check must be conducted as soon as practicable but not later than 24 hours after the triggering event. If your state has a similar registry and mandate, the same architecture applies; if not, the build still works for any contact-the-list-fast mission.

The manual process (and its limits)

The baseline process when activation criteria are met: an automated mass-notification blast (text, email, and phone) asks registrants to confirm they are okay; non-responders get two direct phone calls; then two calls to their emergency contact; then a search for an obituary; and finally a door-to-door in-person check. A phone bank list with a call script supports the callers.

FIG 08 // The wellness-check escalation ladder, from automated notification to a door-to-door check.

Four problems surface as soon as you run this at any scale: limited resources to conduct the activation; registry data that has to be manually downloaded; no notification when new registrants appear; and -- the big one -- not every person is affected by every outage, so blanket activations waste your scarcest resource, callers.

Project goals

• Meet the needs of the residents on the registry.

• Reduce time and energy spent during response.

• Exceed the standard required by the statute -- know about the outage before the 24-hour clock does.

• Deliver an automated system that checks every address on the registry for power outage, is easily replicable across jurisdictions, and integrates with existing systems.

Chapter 15. The Key: ESI IDs and Outage Status

Public utility outage maps are built for the public, not for automation: outages are shown as areas, there is no cross-reference to your registry, and (in our provider’s case) the map’s API URL rotates every ten minutes. The per-address status checker is the way in -- and it keys on the ESI ID.

An Electric Service Identifier (ESI ID, pronounced "Easy I.D.") is a unique number tied to an address in Texas. Unlike a meter or account number, the ESI ID identifies the exact service location and never changes, even if the customer switches retail providers. Structurally it is a provider code, a reserved block, and a premise ID. Free lookup tools exist: the utility’s own ESI ID lookup (by ZIP or city) and third-party address-based lookups.

// NOTE The registry data does not include the ESI ID. Enriching each registrant’s address with its ESI ID -- once, automatically, when the record first arrives -- is what makes per-address outage checking possible. The production pipeline in Chapter 16 does exactly that.

With an ESI ID in hand, the provider’s status endpoint answers for one address. The example below is for one Texas utility; substitute your provider’s checker. If your territory spans several providers, plan a per-provider branch -- the architecture holds.

Chapter 16. Four Ways to Build It

There are four viable implementations, in ascending order of code and descending order of licensing friction. All four share the same core loop: retrieve the registry list, check each address’s power status, update the status column, and notify the team about outages.

Option 1: Power Automate

1. Trigger: Recurrence. Set the timer to every 4 hours (the statutory clock is 24; a 4-hour cadence finds outages early).

2. Retrieve the phone bank call list and clear it.

3. Initialize a variable to store the ESI ID (type: string).

4. Retrieve the master registry list (List rows present in a table).

5. Apply to each row: set the ESI variable, then HTTP GET the provider’s status-check URL with the ESI ID inserted.

6. Parse the response body for the status and update the row’s outage column with YES or NO.

7. If YES: add the person to the phone bank and build an HTML table of affected registrants.

8. Send the HTML table to the team in a Teams chat.

FIG 09 // The Option 1 loop: recurrence, registry retrieval, per-address status check, and the Teams notification.

// NOTE If the list is long, do not post one chat message per person. After the loop, list the rows again, filter the array for Power Status equals OFF, use Select to keep only the columns you want (format: @item()?[‘Column’]), create an HTML table from the Select output, and post one message with the table.

Option 2: ArcGIS Notebooks

1. Connect to the feature layer holding the master registry list.

2. Retrieve the list and iterate the addresses.

3. Check each address against the provider’s status endpoint and update the outage column with ON or OFF.

4. Email the results to the office.

5. Set the run schedule in the notebook’s settings (requires the premium notebooks tier for scheduling).

Option 3: ArcGIS Server (scheduled script)

1. Create the Python file on an internal server.

2. Configure Windows Task Scheduler to run the script.

3. The script connects to the feature layer, retrieves the registry, checks each address, updates the outage column, and emails results to the office.

Option 4: Direct Python (no ArcGIS)

1. Create the Python file on an internal server and schedule it with Windows Task Scheduler.

2. Connect directly to the master registry Excel file instead of a feature layer.

3. Check each address, update the outage column, and email results.

Choosing between them

FIG 10 // ArcGIS output: the console run, the all-clear email, and the live power-status dashboard map.

Scheduling and logging (Options 3 and 4)

1. In Windows Task Scheduler, create the task and set the trigger (daily, repeat every 4 hours for the duration of a day).

2. Create the run action: point Program/script at your python.exe and pass the script path as the argument.

3. On the General tab, select "Run whether user is logged on or not" and "Run with highest privileges," using a service account.

FIG 11 // Task Scheduler setup: trigger, action, and run-without-user settings for the scheduled status check.

Add Python’s logging module to the script (import logging; basicConfig with a file path, INFO level, and a timestamped format). The log file turns "did it run at 6 a.m.?" from a mystery into a one-line answer, and captures connection counts, update totals, and email sends for every run.

Chapter 17. The Production Pipeline

// UPDATED PATHWAY This chapter is the current pathway. The original guide documented the Option 1 starter flow (Excel + HTTP scrape in Power Automate); production later moved to an ArcGIS + Python pipeline with Power Automate handling the Teams-facing pieces. The starter flow remains a fine on-ramp -- and the legacy version of it should be archived (turned off, clearly labeled), not deleted, once you cut over.

The production build is four cooperating automations -- python where the GIS work is, Power Automate where Teams is -- plus a weekly and a 4-hour rhythm.

The four automations

The data update flow

1. Weekly: the state registry feature layer syncs into the local ArcGIS Online layer, adding ESI and Power_Status columns.

2. New residents detected? The pipeline scrapes the ESI lookup for the new address and adds the number; the refreshed list is sent to the mass-notification platform, which updates contacts. No new residents -- do nothing.

3. Every 4 hours: the status script checks power for every address and updates the layer.

4. Outages found? The Power_Status column is overwritten ON/OFF, an email goes to the office, and Power Automate uploads the Excel file to Teams and adds affected registrants to the phone bank dashboard. No outages -- do nothing.

FIG 12 // The production data update flow: weekly registry sync on the left branch, 4-hour outage checks on the right, both landing in Teams.

// UPDATED PATHWAY The phone bank itself moved from a static spreadsheet to a SharePoint list. When the outage email arrives from ArcGIS with the affected-registrant Excel attached, a flow creates one phone bank list item per person -- so callers work a live, assignable list with a positive-contact column, and the incident dashboard reads the same list. The earlier registry-intake flow that predates the ArcGIS pipeline stays archived.

Public-facing groundwork

The technology only matters if the registry is populated and registrants respond. Two mailers carry the load: a water-bill insert explaining who should register and how (online, 2-1-1, or by email), and a pre-test letter before each system test telling registrants exactly what the notification will look like and how to respond -- confirm to stay on the registry, or opt out. Non-responders get a personal call; if there is no answer, staff call the emergency contact to verify the information is correct. Keep a copy of the outbound test message next to the phone bank script so callers can answer "what was that text I got?" verbatim.

Known limits and next steps

• The registry data does not include ESI numbers -- the sync automation must keep enriching new records.

• Python has a hard time talking to Microsoft: hand Teams-facing work to Power Automate rather than fighting the Graph API from a script.

• Connect the mass-notification platform to the phone bank system so response status flows back automatically.

• The example covers one service provider; multi-provider territories need a branch per provider.

// PART V //

Reporting, tracking, the incident room pattern, SITREPs, T-cards, and AARs

Chapter 18. Activity Reporting

An active team is constantly involved in projects and in contact with multiple jurisdictions. The activity reporting system organizes these activities and produces accurate performance metrics for yearly reviews, while documenting the coordination work your team does.

REPORT FORM SUBMITTED → POST TO SECTION ROOM → REPORT LOG UPDATED → POWER BI UPDATES GRAPHS

The form can be built in any form maker -- MS Forms and Smartsheet are the two easiest. Selecting the report type populates type-specific questions: Contact, Activity, Meeting, Training, or Exercise.

Report type definitions

• Contact. Informal communications with external partners -- in person, by phone, or virtual; either side can initiate. Do not double-log: if the communication is part of a planned meeting, training, or exercise on the same topic, it belongs in that entry.

• Activity. Internal events or actions essential to the job that fit no other category but are significant enough to record -- project work, for example.

• Meeting. Formal internal or external meetings, typically scheduled in advance -- council-of-governments meetings, team meetings, commissioners court, operational briefings.

• Training. Internal or external trainings attended, virtual or in person.

• Exercise. Exercise participation in any role -- observer, controller, evaluator, player, or support.

Common fields, and the ones that trip people up

• Event date, main topic/title, method of communication, detailed description, and file upload appear on most types.

• Location is always the location being supported, not where the employee is assigned; the system automatically catalogs the submitter’s assigned area. External events use the partner’s location, internal events the employee’s work location.

• Multi-day meetings, trainings, and exercises get one entry per person; record total days in the description. Training hours must match the certificate (a 3-day, 8-hour course logs 24).

• For trainings, record the official course title and the course number (for example, G-300); if no number exists, repeat the title.

Chapter 19. Incident Reporting

Under ICS there is a clear, if overwhelming, way of tracking incident information. For responders it takes time and becomes a distraction. Our House keeps the ICS foundation but uses technology so responders report in real time and the EOC consolidates automatically.

The working Incident Report form -- five report types, full incident taxonomy -- already lives in Checklists.

The five report types

• Initial. Records the initial report for an incident and auto-posts a formatted report to the appropriate rooms. Incident-type-specific questions populate based on the type selected. One person submits per area of responsibility.

• Initial/Final. For incidents opened and closed in one report; same behavior, one submission per AOR.

• Update. A status update/SITREP entry for the incident. Auto-posts as a reply to the original initial report -- select the incident from the dropdown so the thread connects.

• Final. The incident summary; auto-posts as a reply to the original thread. One person submits per AOR.

• Engagement. Records each employee’s level of involvement and hours. Levels: ASSIST (information or technical assistance), COORDINATE (aiding resource management), RESPOND (physically deploying). A RESPOND supersedes assists and coordinations for the same window; multi-day incidents need an entry per day.

The form, field by field

• Event date; status (report type); incident type -- primary and secondary from dropdowns, multi-select as needed (the taxonomy spans high-profile incidents, severe weather, fire/rescue, EMS, law enforcement, public health/mass care, CIKR, and transportation).

• HAZMAT involved; LE-sensitive (marks the report not-for-distribution); incident title (quick-reference, e.g., "Power Plant Fire"); incident number if applicable.

• Incident location -- the location being supported, not the submitter’s assignment; the system catalogs the submitter’s assigned location automatically.

• Responding agencies (comma-separated); active EOCs and active shelters (counts, with names in Notes); commodities distributed (count, details in Notes); unmet needs; detailed description.

// NOTE When formatting the auto-posted report, write your own column set based on your form questions -- and scrub anything privacy-sensitive before it posts to a broad channel.

Chapter 20. Incident Tracking and the Master Database

Information from the incident forms feeds a master database the EOC uses to keep the current picture. Because the activity and incident logs post to the specific rooms, the Posts feed becomes a running "CAD" of everything happening in that AOR -- and the databases update the SITREP automatically, which is where the time savings land.

Chapter 21. The Incident Room Pattern: Lifelines, EOC Level, and Updates

Presenting incident status to stakeholders is hardest during the fight. This chapter is the heart of incident operations in Our House: a dashboard for FEMA lifelines and EOC activation level, a set of SharePoint lists as the state, and flows that make one change ripple everywhere -- into history, into the incident room, and onto the dashboard.

The dashboard

The dashboard is built in Power Apps. The lifelines and the EOC level are clickable; a click changes the status, which is stored in a SharePoint list.

FIG 13 // The lifeline dashboard: click a lifeline or the EOC level to change status; everything else follows.

The four core lists

• EOC Activation Level -- columns: Title, Level (choice), IncidentNumber. It will only ever have one item.

• Lifeline Status -- columns: Title, Color (choice), IncidentNumber. It will only ever have eight items, one per lifeline.

• EOC Activation History -- columns: Activation Level, IncidentNumber, DateTimeChanged.

• Lifeline Status History -- columns: Lifeline, Color, DateTimeModified.

Walkthrough: the lifeline status flow

1. Trigger when an item in Lifeline Status is modified.

2. Get the changes for the item.

3. Check whether the Color column was updated.

4. If yes, create a record in the Lifeline Status History list.

5. List the channels in the team.

6. Filter for the incident number in the channel name -- this is why incident rooms carry the number in their names.

7. Post the change message to the matching incident room.

The EOC activation flow is the same shape: state list changes, history is written, and the incident room gets the post.

// UPDATED PATHWAY The current build extends the pattern in three ways. First, when the EOC activation level changes, the flow also stamps the current incident number onto the Lifeline Status list and the ESF task list -- so every subsequent status change and task record is automatically tied to the right incident. Second, the plan itself joins in: modifying an ESF’s entry in the plan list triggers a flow that flips that ESF’s tasks to active, and a companion flow logs every completed, N/A, or annotated task to an ESF Task History list (as long as the incident number is unchanged). Third, every post made in an incident room is captured by a flow into an Incident Channel History list -- the incident room is the live timeline, the history lists are the audit trail, and the dashboard is the read-only rollup.

Chapter 22. Department Updates and Resource Requests

During an incident, departments need a way to submit updates and requests (the 214 and 213RR of it all) without radio traffic or email chains.

The Department Incident Update form

• Incident number -- the OEM-issued number for tracking.

• Department -- select the one you represent.

• Description of issue/update, and the solution or department response taken.

• Do you have unmet needs? If yes, an Unmet Needs box appears -- type the resource request.

Walkthrough: the update flow

1. Standard start for a form submission.

2. List the channels in the team that holds your incident rooms.

3. Add a condition checking for the incident number in the channel name (this creates an Apply to each -- that is fine).

4. Inside the match, add a condition: unmet needs equals yes.

5. Either way, post a message with the update first.

6. If yes, create a task and make the title the unmet need.

7. Update the task details with the information from the form.

8. Reply to the posted message with a link to the task, so the request and its tracking are joined in the thread.

// UPDATED PATHWAY Production hardened the unmet-needs half into a proper Resource Request list. When an item is created, a flow emails the office that a request exists. When the assigned-department column is filled, a second flow sets the status to Assigned, posts to the incident room tagging that department’s POC, and emails them directly -- so assignment is one column edit, and nobody has to notice a task appear. If you outgrow the task-based version, this is the shape to grow into.

Chapter 23. Situation Reports, T-Cards, and AARs

The SITREP

All the data collected during an incident combines into a SITREP for the incident commander and stakeholders -- a task that often takes an entire team. Our House pulls from the incident form inputs and turns them into a dynamic SITREP in whatever format your agency expects, ICS 209 or otherwise.

Where a dedicated SITREP form is wanted, the user selects their department and answers pre-drafted leadership questions: priorities for the period, actions taken, service impacts (often the unmet needs), and notes. The SITREP itself is built in Excel and uses cell formulas to pull the latest answers from the form responses -- the key formulas are in Chapter 28.

FIG 14 // The Excel SITREP: formulas pull each department’s latest submission into the printable report.

// UPDATED PATHWAY Keep the raw form-response workbook and the working SITREP workbook separate. Form-connected workbooks belong to the form; the submission flow appends each response to the working SITREP workbook (and posts it to the incident room), while the raw-responses file stays untouched as the source of record. Name them so no one confuses the two, and version the working workbook (V2, V3) rather than editing its structure mid-incident.

T-cards (resource tracking)

T-cards are an extremely useful tool that is no longer prevalent -- and physical boards require the IC to stand where the board is. Our House enters 213/T-card data through a list form, which drops the card on a board viewable by anyone with access to the incident room.

1. Add columns to a SharePoint list: Resource Type (Crew/Team, Engine, Helicopter, Personnel, Fixed-Wing, Equipment, Miscellaneous Equipment, Generic), Location (Staging, EOC, ICP, and so on), plus any other T-card boxes your solution requires.

2. Under the Location column, set the default value to "Staging."

3. Select "Add view," name it "Board," choose "Show as board," organize the board by the Location column, and click Create.

4. To color the cards by resource type, click the view name, select "Format current view," and paste the board-formatting JSON from Chapter 28 into the JSON area.

5. Create the list form, selecting the columns that match the boxes on a physical card -- that form is how the 213 data gets entered.

FIG 15 // The T-card board: list items shown as cards, organized by location, colored by resource type.

After-action reports

Collecting and processing AAR data from every responder and agency is a challenge. Our House provides one form that collects from all teams in the incident and combines the results into an easy-to-manage AAR. Fields: incident number; department; department response overview -- which should include metrics (total cubic yards of debris hauled, days a cooling station was open, residents served, press releases posted); what went well; and up to five problem boxes, each of which must be paired with a solution or potential solution. The AAR document is built in Excel with formulas pulling from the form; the office finishes the narratives and routes each issue/solution to the responsible party.

// PART VI //

Turning chaos into coordination

“All disasters are projects; not all projects have to be disasters.”

-- CONFUCIUS (OR WILLIAM L. WAUGH JR.)

Chapter 24. Why Project Management

Emergency management is full of projects -- we just don’t always call them that. Developing a new EOC dashboard, updating an emergency operations plan, or running a full-scale exercise: each follows a defined scope, schedule, and resource set. Project management helps us move from reactive emergency management to proactive execution, keeping people aligned even when incidents interrupt daily operations.

What project management is

Project management is the disciplined application of knowledge, skills, tools, and techniques to deliver value and achieve objectives. Four traits define a project: it is goal-oriented (defined outcomes), structured (a defined process), time-bound (every project has a beginning and an end), and collaborative (it requires team coordination). The core elements a project manager watches are scope, schedule, budget, quality, risk, stakeholders, and communication.

The numbers

The last two rows are the point. EM curricula emphasize ICS, response tactics, and planning theory, but often not structured methods like risk registers, earned value, or agile iteration. Many practitioners adopt on-the-fly approaches rather than structured frameworks -- while managing multimillion-dollar portfolios.

EM projects, by phase

• Preparedness: EOP updates, training and exercises, public outreach.

• Mitigation: hazard mitigation plans, infrastructure upgrades.

• Response: EOC activations, resource deployment systems.

• Recovery: debris removal, public assistance, after-action reviews.

The value, and the shift

What structured PM buys an EM office: clarity of scope, structured coordination, schedule discipline, improved communication, performance metrics, and continuous improvement. Without it, the office runs reactive emergency management; with it, intentional planning and measurable outcomes. That is the shift from reactive to proactive.

Chapter 25. Lifecycle, Risk, and Stakeholders

The project lifecycle

FIG 16 // The five phases. Monitoring feeds back into execution until closure criteria are met.

Initiation defines why and whether; planning defines what, when, and who; execution does the work; monitoring and control measures against the plan and feeds corrections back; closure verifies, hands off, and archives. Chapter 26 maps an ICS-numbered artifact to each phase.

Choosing a framework

Risk management

The common project risks in EM are the ones you already know as hazards to your own work: funding delays, staff turnover, schedule slippage, compliance changes, scope creep, and external disruptions -- including the activation that pauses everything. Risk management in action looks like this: a construction delay doesn’t stop the project, we resequence tasks; if a stakeholder drops out of an exercise, injects can test backup communication; if federal guidance changes mid-grant, we document the change and adapt the scope.

The tool is a risk register: each risk scored for likelihood and impact, with a mitigation strategy and an owner. An example:

// NOTE Score residual risk after mitigation, and give every accepted or escalated risk a decision -- that is exactly what the ICS 215A form at the end of this part captures.

Stakeholders and communication

Assign RACI roles -- Responsible, Accountable, Consulted, Informed -- so nobody wonders whose call it is. Write the communication plan down: weekly status reports for directors, monthly briefings for councils. And keep the balance in view: a project lead’s job is equal parts technical execution and relationship management.

Chapter 26. Tools, Practice, and the ICS Artifact Set

STRUCTURE → TECHNOLOGY → COMMUNICATION → PROJECT SUCCESS

Tool categories

In practice: the Projects list

This is where the book comes full circle. The Projects tab built in Chapter 4 is the office’s project management system: every work item carries a description, category, progress, priority, dates, assignment, and a running comment thread; the grid view is the portfolio, the board view is the kanban, and attachments live on the item. Reviewed weekly, it is the single source of truth the rest of this chapter’s tooling reads from.

FIG 17 // The kanban pattern: backlog, doing, review, done. The Projects list’s board view gives you this natively.

Dashboards and automation

Roll the portfolio up into a visual dashboard -- Power BI, ArcGIS, Smartsheet, Tableau, or Looker Studio all work -- showing total projects, projects in progress, assignment distribution, categories, and priority items with notes. Then automate the housekeeping with the connective tissue from Part I: task reminders, milestone notifications, and automatic reports, so the system nags so you don’t have to.

Documenting and tracking progress

• Manage and store artifacts in software, not binders on one person’s desk.

• Adopt standard naming conventions (Part IX exists because this matters).

• Encourage version control -- versions, not "final_v2_REAL."

• Build a project archive binder per project: charter through closeout, in one place.

Integrating artifacts with ICS

Emergency managers already know a documentation system -- ICS. This artifact set maps each standard PM document onto the ICS form number that thinks the same way, so the discipline feels familiar on day one:

Success factors

Standardized templates, centralized file storage, visible project dashboards, regular progress reviews, project leads with real authority to make decisions and access budget, and leadership that trusts the numbers on the dashboard. Three things to keep in mind: EMs manage projects daily -- they just don’t call them that; project management adds structure, accountability, and foresight; and building PM skills improves resilience across all EM phases.

The nine templates, reproduced as they are. Landscape forms are rotated to fill the page. Each form carries its own instructions in-line; use them directly or rebuild them in your own template system.

The full ICS 201–221 crosswalk templates already live as downloadable Word docs there -- no need to recreate them here.

Telling the story of your workload

Chapter 27. Reports and Performance Metrics

Our House collects a great deal of data reflecting the work your department does in service of your residents. Build dynamic reports that highlight that work: they tell the story of your workload to support equipment, staffing, future planning, and other budgetary requests.

Build reports where the dashboard lives

We recommend managing reports in Power BI, in the same file as your dashboard, so leadership can reach them faster. Reports shown throughout this guide were generated from fabricated data.

Three capabilities worth wiring in

• GIS integration. A full-screen ArcGIS map tracks outreach across the AOR, and public or jurisdictional layers -- hurricane paths, population density, wildfire index, tornado tracks, damage assessment data -- overlay your own data to support decisions with history.

• Drill-through. Power BI graphs are interactive and filter on selection. Right-click a visual and choose drill-through to jump to a filtered summary table of the underlying reports.

• Mobile. Power BI ships a mobile layout for every report -- build it, because leadership will ask from the road.

// PART VIII //

The formulas, snippets, and tricks behind the walkthroughs

Chapter 28. The Toolbox

We are sharing the structure and use cases of Our House for you to make it your own and build something for free using the tools at your disposal. Similar concepts can be built in any format using any program. Bottom line: use what you have to build what you need.

The sample data tree

From a previous build, the depth of forms and logs behind each report. An incident report draws on the initial report log, commodity distribution, critical infrastructure, EOC, exercise, shelter, special event, registry, and transportation logs. A SITREP adds status databases: EOC, shelter, government and school closures, healthcare, declarations, and external feeds. Weekly reports, contact reports, travel requests, and performance metrics each carry their own log. Map the tree before you build -- every report you promise implies logs you must maintain.

Smartsheet to Teams (JSON conversion)

If your agency uses Smartsheet, you will quickly find it is not easy to get data into usable objects for Teams. This flow converts a Smartsheet row’s HTML into JSON:

1. Trigger: When a new row is created

2. ReplaceTR: replace(triggerOutputs()?['body/rowHTML'],'</tr>','|</tr>')

3. ReplaceTD: replace(outputs('ReplaceTR'),'</td>','^</td>')

4. ReplaceSpace: replace(outputs('ReplaceTD'),' ','_')

5. HTML to Text: outputs(ReplaceSpace)

6. NewLine: " " (a compose containing a newline)

7. ReplaceNewLine:

replace(replace(outputs('Html_to_text')?['body'],outputs('NewLine'),''),'_',' ')

8. Rows: skip(split(outputs('ReplaceNewLine'),'|'),1)

9. Filter Array: length(trim(item())) greater than 0

10. Debug: split(First(body('Filter_array')),'^')

11. Select: split(item(),'^')[0]

12. Parse JSON

Getting a schema for Parse JSON

1. Create the Parse JSON step and add the JSON output you want to parse (usually the body of the previous step). Leave the schema box blank.

2. Run the flow. It will fail -- this is okay.

3. Open the failed run. The Parse JSON step’s content box contains the input as JavaScript; copy it.

4. Back in the editor, select "Generate from sample."

5. Paste the copied content and click Done. The schema appears in the schema box.

Building reports from forms in Excel

MS Forms stores responses in Excel, and it is convenient to build the report (like the SITREP) in the same workbook so it runs faster. Excel opens Sheet 1 first, and once a file exists you can never change which sheet is Sheet 1 -- so build the workbook first, then create the form from inside it (Insert > Forms). That also lets you choose where form data is stored.

Indexing the latest answer per department into the SITREP:

=IFERROR(INDEX(Form1!$M:$M,

MATCH(MAXIFS(Form1!$C:$C, Form1!$F:$F, 'STATUS REPORTS'!A38,

Form1!$O:$O, $A$4),

Form1!$C:$C, 0)), "Not Found")

Reading it: $M:$M is the question column to return; $C:$C the completion-time column; $F:$F the department column matched against the department name on the report sheet; $O:$O the incident-number column matched against the incident cell on the main sheet. MAXIFS finds the latest matching submission; INDEX/MATCH returns its answer.

Listing every "Not Working" column from the most recent entry:

=TEXTJOIN(CHAR(10), TRUE,

IF((C:C=MAX(C:C))*(ISERROR(SEARCH("Not Working", H:AG))),

H$1:AG$1 & " - " & H:AG, ""))

CHAR(10) separates results with new lines; C:C is completion time; H:AG are the question columns searched; H$1:AG$1 supplies the column titles for the output.

Calculated columns in Lists

The NIMS build marks a person compliant when every required course column is Yes:

=IF(AND([Column1]="Yes",[Column2]="Yes",[Column3]="Yes"),"Yes","")

Separate the columns by commas; AND requires all to be true; the formula returns Yes when they are and blank otherwise.

T-card board formatting (JSON)

The board view is colored with SharePoint’s board-formatting schema. The essential structure below sets the card container and colors by resource type; extend the displayed fields to match your card boxes.

{

"$schema": "https://developer.microsoft.com/json-schemas/sp/v2/board-formatting.schema.json",

"hideSelection": false,

"formatter": {

"elmType": "div",

"attributes": { "class": "sp-card-container sp-card-container-noPadding" },

"children": [{

"elmType": "div",

"attributes": { "class": "ms-bgColor-white sp-css-borderColor-neutralLight

sp-card-borderHighlight sp-card-subContainer" },

"style": {

"background-color":

"=if([$ResourceType] == 'Crew/Team Card', '#ccffcc',

if([$ResourceType] == 'Engine Card', '#ffcccc',

if([$ResourceType] == 'Helicopter Card', '#add8e6',

if([$ResourceType] == 'Personnel Card', '#d3d3d3',

if([$ResourceType] == 'Fixed Wing Card', '#ffa07a',

if([$ResourceType] == 'Equipment Card', '#d2b48c',

if([$ResourceType] == 'Generic Card', '#ffb6c1', '')))))))"

},

"children": [ /* one p element per displayed column, e.g.: */

{ "elmType": "p",

"attributes": { "title": "[$Cat]", "class": "sp-card-content" },

"txtContent": "=if([$Cat] == '', '–', [$Cat])" } ]

}]

}

}

The wellness-check Python script

The production status-check script, cleaned for print. Replace every placeholder in angle brackets; the outage URL shown is one Texas provider’s public status endpoint -- substitute your own provider’s.

from arcgis.gis import GIS

import pandas as pd, requests, smtplib, logging

from email.message import EmailMessage

from tqdm import tqdm

logging.basicConfig(filename=r"C:\ScheduledTasks\Logs\PowerStatus.log",

level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s")

def email_alert(subject, body):

msg = EmailMessage()

msg["Subject"] = subject

msg["From"] = msg["To"] = "oem@<your-agency>.gov"

msg.set_content(body)

with smtplib.SMTP("mail.<your-agency>.gov") as smtp: # internal relay; check with IT

smtp.send_message(msg)

gis = GIS("home") # 1. connect to your GIS

item = gis.content.search("title:MasterRegistryList type:Microsoft Excel",

max_items=1)[0] # 2. load the registry workbook

df = pd.read_excel(item.download())

esi_list = df["ESI"].dropna().astype(str).unique() # 3. unique ESI values

layer = gis.content.get("<your-layer-item-id>").layers[0] # 4. feature layer

features = layer.query(where="1=1",

out_fields="ESI, External_ID, Power_Status", return_geometry=False).features

esi_to_ext = {str(f.attributes["ESI"]).strip(): str(f.attributes["External_ID"]).strip()

for f in features if f.attributes["ESI"] and f.attributes["External_ID"]}

updates, errors = [], [] # 5-7. check status per ESI

for esi in tqdm(esi_list, desc="Checking ESI power status"):

try:

url = ("https://www.oncor.com/outages/api/customerOutage/outage/"

f"checkStatus?esiid={esi}&source=ORS") # substitute your provider

data = requests.get(url, timeout=10).json()

status = "OFF" if data.get("powerStatus","").strip().upper()=="OFF" else "ON"

ext = esi_to_ext.get(esi)

if ext: updates.append({"attributes":

{"External_ID": ext, "Power_Status": status}})

else: errors.append((esi, "External_ID not found in feature layer"))

except Exception as e:

errors.append((esi, str(e)))

if updates: # 8. apply updates

layer.edit_features(updates=updates)

off = [] # 9. compile OFF contacts

for u in updates:

if u["attributes"]["Power_Status"] == "OFF":

row = df[df["External_ID"].astype(str)==u["attributes"]["External_ID"]]

if not row.empty:

r = row.iloc[0]

off.append(f"Name: {r['First_Name']} {r['Last_Name']}\n"

f"Address: {r['Street_Address_1']}, {r['City_1']}\n"

f"Phone: {r.get('Phone_1','N/A')}\n")

if off: # 10. notify

email_alert("Registry Power Notification",

"The following contacts are reporting power OFF:\n\n" + "\n---\n".join(off))

else:

logging.info("No OFF records found. No email sent.")

// NOTE The email in this script contains registrant names, addresses, and phone numbers -- personally identifiable information. Send it only to the office mailbox, never to a broad channel, and make sure the log file records counts, not contact details.

A live weather feed in the SITREP

1. In Excel, select the Data tab, click "Get data" > "From other sources" > "From web."

2. Enter the forecast URL for your area, substituting your latitude and longitude: https://nimsiap.org/fwx2.php?lat=<your-lat>&long=<your-long>&inam=1, then click OK.

3. Click "document," then Load.

4. Open Queries & Connections, double-click the query, then drill in: click "Table" in the Data column, "Table" in Children, and "Table" in the Children column of the BODY row.

5. Select the Text column, choose "Remove other columns," then run Replace Values three times to strip markup. The end result is a one-cell table with the forecast.

6. Click "Close & Load." The SITREP now carries a refreshable NWS forecast.

Chapter 29. The Google Workspace Crosswalk

Not every agency lives in Microsoft. Everything in this book translates to Google Workspace -- but Google’s tools are shaped differently, so a literal click-for-click port does not work. This chapter is the crosswalk: which Google tool stands in for which Microsoft tool at every layer of the house, what you gain and lose, and the setup discipline that replaces what Google doesn’t give you. A full companion manual walks the build section by section; this chapter is the map.

The house metaphor, translated

Tool-by-tool crosswalk

What you gain and lose

• You lose: the native Teams tabs model -- Google Chat is flatter, so pinned messages and naming conventions do the work tabs used to do; Planner’s built-in board UX, rebuilt in AppSheet or a Sheet-based board; Power BI’s deep DAX modeling -- Looker Studio is capable but less powerful for complex data; and automatic Space-to-folder linkage -- Google requires a manual link step per Space.

• You gain: lower licensing friction, especially for smaller agencies or partners without an M365 tenant; faster mobile deployment through AppSheet with little to no code; more flexible general-purpose scripting through Apps Script (JavaScript); and simpler external and public collaboration boundaries.

Foundation discipline: Shared Drives and naming

Build on Shared Drives, never My Drive: files in My Drive are owned by an individual and follow them if they leave, while Shared Drive content is owned by the organization. Because Google Chat has no tab structure, naming discipline replaces it -- adopt a fixed pattern from day one: Space names like "OEM | Response" or "OEM | Incident | 2026-01 Ice Storm," with the matching Shared Drive folder named identically so Space-to-folder is never ambiguous.

Standing up a room (Chat Space)

1. In Google Chat, click the plus next to Spaces, then "New space."

2. Name it using the convention above (for example, "OEM | Response").

3. Add a description stating the room’s purpose -- your only substitute for a channel’s context, since there is no tab to hold it.

4. Add members; owners should mirror who would have been Team owners in the Microsoft build.

5. Open Space settings, choose Files, then "Link a Drive folder," and connect the matching Shared Drive folder.

// NOTE Google cannot auto-create folders when a Space is created, and one Shared Drive cannot automatically fan out to multiple Spaces. Every Space-to-folder link is a manual, one-time action -- budget for it as a checklist item whenever you stand up a new room.

From there the build order mirrors this book: furnish the rooms (Sheets as the lists, Forms as the intake, AppSheet as the apps, Looker Studio as the dashboard), then layer in the workflows -- inventory, approvals, PAR, vulnerable population tracking, incident reporting, AAR -- rewriting each Power Automate flow as an Apps Script triggered on form submit or on a time schedule. The concepts carry over one for one; only the plumbing changes.

// PART IX //

Naming, maintenance, and continuity for the system itself

Chapter 30. Naming and Maintenance

A system this connected accumulates entropy: flows reference lists by name, dashboards read files by path, and a rename in one place is a silent break in three others. This closing chapter is the practice that keeps the house standing -- learned the hard way from running a build for years.

Name things once

• Pick one canonical name per object and use it everywhere -- in the flow, the form, the file, and the tab. "ESF Tasks" and "ESFTasks" will read as two objects to the next maintainer.

• Never let two files share a name, even in different folders. If a legacy filename cannot change without breaking connections, disambiguate it in documentation with a parenthetical.

• Delete or rename "Untitled" anything the day it appears.

• When a list and a file exist for the same data, one of them is stale. Decide which is canonical, point every consumer at it, and retire the other.

Protect the plumbing

• Keep flow-referenced workbooks in one clearly named folder -- ours is literally called "DO NOT TOUCH" -- and never move or rename files inside it.

• Check flow targets before renaming or removing any channel; many flows post to channels by name.

• Avoid hardcoding individual recipients in flows. Use a shared mailbox or role-based list where one exists; where it does not, write the dependency down so a personnel change triggers the update.

• Archive retired flows -- turned off and clearly labeled -- rather than deleting them immediately or leaving them ambiguously live.

Keep a maintenance register

Build a register -- a SharePoint list, naturally -- of everything that needs periodic attention or can break silently: cleanup items pending, archived flows, hardcoded dependencies, external dependencies (the outage API, the mass-notification sync), and scheduled jobs to verify. Give each row an action, a cadence, and a next-review date, then let a scheduled flow email the office whatever is due. The register doubles as COOP documentation for the system itself: if the builder wins the lottery, the register is where the successor starts.

Thank You

Thank you very much for all the hard work you do in your community.

If you have any questions about the Our House system or the content in this guide, please reach out.

Email: ourhousesandbox@gmail.com

Our House · book edition · © Ryan Steele, Sarah Haak 2025–2026 · screenshots are examples of outputs from a working build; sample data is fabricated