On the inside, you’re stuck in firefighting mode. Every problem, every decision, every “quick question” still comes back to you.

You’re asking:

• “Why does everything still live in my head?”

• “Why can’t my team execute without me in the middle?”

• “How do I get out of day to day operations…so I can work ON the business?”

In this live webinar, Todd will show you why you may not have a time management problem—you may have a business design and handoff problem.

Ask a question. Get an answer. Keep a record.

We're excited to introduce RFIs to Ressio — a formal question-and-answer workflow that's a construction industry staple, long common in commercial projects and increasingly requested by residential builders. You asked for it, and it's here.

What's an RFI?

An RFI is a more structured alternative to a regular message. Instead of an open-ended back-and-forth, an RFI is tied to a specific topic or file, has a clear due date, and moves through a defined approval process — so nothing falls through the cracks and everything is documented.

Where to find it

RFIs live at the project level. Look for the new RFIs tab in the left-hand navigation within any project.

Key features

The three A's

Every RFI is built around three roles:

• Assignee(s) — responsible for answering the question. You can add more than one, and at least one is required.

• Approver(s) — reviews and approves the final answer. This is usually the person who submitted the RFI, but the work can be delegated to other team members, and multiple approvers can be added.

• Audience — read-only participants who stay in the loop without being part of the formal approval process (great for keeping other subs, team members, or clients informed).

Two-way communication

RFIs aren't just for builders. Builders can send RFIs to team members, clients, or vendors — and vendors can send RFIs back to builders as well. (Note: vendors can only submit RFIs to builders, not to other subcontractors.)

Flexible details

When creating an RFI, you can include:

• A title (often phrased as the question itself)

• A description for additional context

• An optional subject

• A related file (e.g., a spec or drawing)

• An optional due date — one of the most powerful parts of the RFI workflow

Built-in conversation and formal answers

Once an RFI is released, assignees can send regular messages to ask clarifying questions — and then formally submit a message as the official answer, which becomes the current answer of record.

Approval workflow

As the approver, you can:

• Accept the answer (with optional comments), which updates the RFI to Approved and Closed

• Request clarification, which reopens the RFI and allows the assignee to submit a new answer

Full activity history

Every RFI includes a complete activity log, so you can track questions, answers, clarifications, and approvals from start to finish.

Notifications

Releasing an RFI triggers email and text notifications, just like other approvals and messages in Ressio — and you can send an accompanying message right away with added context or attachments.

Privacy by design

Only the following people can see a given RFI: project admins, and anyone listed as an approver, assignee, or audience member on that RFI.

Use it your way

RFIs support both:

• Formal, traditional RFI processes with due dates, approvals, and documentation, and

• Lightweight, informal conversations among a select group of people (team members, subcontractors, clients)

Here's a summary from me working through AI (below) -- basically, I've been messing around with dashboards / data aggregation and thought it would be cool if I could scrape daily logs from all projects on a daily basis, and get a quick email summary about items within if there were questions or if a question was detected, with the ability to automatically reply to daily logs directly with a quick 'thanks' or 'thank you' to the employee user (to encourage daily log use). Found out that's not really possible.

I also thought it would be nice to automate messages to employees through Ressio for different reasons -- reminders, weather alerts, quarterly tasks, encouragement, anything -- but y'all's back end doesn't allow that either.

So, all that said, here's what AI told me to write to you guys:

---

The limitation

sendMessage only accepts a costItemId. But getMessages returns messages with a generic entityType / entityId pair, and in my own project data I'm seeing at least four types in active use: CostItem, Project, Todo, and DailyLogEntry. So the underlying model clearly supports messages on any of these -- the write tool just hardcodes cost items.

What I'd love: let sendMessage accept an entityType + entityId pair (or add dailyLogEntryId / projectId-scoped variants) so it can post to the same targets the read side already returns.

Two concrete use cases driving this:

1. Daily log replies. Read the day's logs across all active projects, flag anything that needs my attention, and post a short reply back on logs that don't. Right now I can create a new daily log via the API but can't reply to an existing one, which isn't the same thing at all.

2. General project messages. Encouragement notes, announcements, reminders to the crew -- posted at the project level, not buried on a cost item.

If there's a way to send a message directly to a user rather than to a project entity, that'd be useful too.

The bug

When I passed a DailyLogEntry ID into costItemId to see what would happen, the call returned:

```

Invalid prisma.costItem.findUniqueOrThrow() invocation:

An operation failed because it depends on one or more records that were required but not found.

```

Fair enough -- except the message row still got created. I pulled getMessages afterward and there it was, with entityType: "CostItem" and entityId set to my daily log's ID, pointing at a cost item that doesn't exist. So the write commits and then the lookup throws.

Practical risk: an automation hitting that path would report failure every run while quietly generating orphaned message records. Looks like the validation just needs to happen before the insert.

=-=-=-=-=-=-=-

Again... most of that was AI generated after my attempts to automatically generate messages under daily logs failed... do with that what you will.

See attached – this is the Cost item drop down in JT