Feature Requests

Allow each contact linked to a transaction to carry a transaction-specific role label or custom tag, such as seller, buyer, bankruptcy counsel, cooperating agent, lender processor, or other. The label should display on the transaction without changing the contact's global CRM type and should support multiple contacts with distinct roles on the same deal. This would let records such as seller bankruptcy counsel be linked accurately without misusing closing_attorney, vendor_contacts, co_agent_id, or referred_by_contact_id.

Danek Znika · Sep 4, 2026

Feature Request: Authenticated Read-Only SkySlope Document Access for Andy AI and MCP Problem: Brokerworks Transactions can be linked to protected SkySlope files, but Lola/Andy AI cannot currently inspect the associated checklist or documents through Brokerworks. Verified calls to skyslopeChecklistForTransaction and skyslopeReadDocument returned “Unauthorized” because the tool session was treated as anonymous. This forces Lola to rely on manual SkySlope review, email attachments, or Drive searches—even when the authenticated agent should already have permission to view their own SkySlope files. Requested Capability: Pass the authenticated Brokerworks user identity into approved Andy AI/MCP calls, or use a scoped service identity mapped to that user. Authorized agents, transaction coordinators, and administrators should be able to: • View checklist items and document metadata for a linked Transaction. • Read or download a specific filed document. • See document versions, upload and completion dates, checklist status, and signed/executed status or missing signers when available. • Cross-reference contracts, amendments, disclosures, Letters of Direction, closing documents, and other transaction evidence. • Maintain accurate timelines and identify follow-up needs when required documents are missing, incomplete, outdated, or unsigned. Security and Behavior Requirements: • Enforce tenant, Transaction ownership, user role, and document-level authorization server-side. • Keep access strictly read-only. • Do not permit uploads, edits, deletions, file binding or rebinding, signature actions, emails, task creation, or other mutations. • Use short-lived document URLs and audit document access. • Return distinct errors for unauthenticated users, unauthorized users, unbound files, missing documents, and SkySlope provider failures. • Transaction-scoped access is sufficient; bulk SkySlope file discovery is not required. Acceptance Criteria: 1. An authenticated Danek/Lola session can view checklist and document metadata for a Danek-owned, SkySlope-linked Transaction. 2. Lola can read or download a named document through Brokerworks without requiring a separate SkySlope browser login. 3. Signature and completion metadata can be used for timeline management and follow-up analysis. 4. Unauthorized users remain denied. 5. No read operation causes a Brokerworks or SkySlope mutation. 6. Approved Andy AI/MCP calls no longer reach Base44 as anonymous.

Danek Znika · Sep 13, 2026

Give Andy AI/MCP read-only access to FeatureRequest records the authenticated user is permitted to view. Andy should be able to: • Search requests by keywords and semantic similarity. • Read the title, description, status, requester, dates, and visible admin responses. • Identify exact duplicates and substantially similar requests. • Explain the overlap and point users to the existing request before recommending a new one. This must not authorize Andy to create FeatureRequests, upvote, comment, or modify anything automatically. Read and duplicate-detection operations must be side-effect-free. Optionally, allow an authenticated requester to revise the title or description of their own FeatureRequest while it remains open. Revisions must require explicit confirmation, preserve version history, record who changed it and when, and prevent changes to requester identity, status, votes, or admin-controlled fields. Requests belonging to others—or no longer open—must remain read-only.

Danek Znika · Sep 13, 2026

My 301 N Lincoln listing was reduced from 275k to 269k. But this is not reflected in the BW transactions tab. Feature Request: Auto-Sync Transaction Fields from MLS Changes, with Compliance Safety Net Problem: When a linked MLS listing changes (most commonly list price, but potentially status, key dates, etc.), the corresponding Transaction record in Brokerworks does NOT update automatically. The two records — MLSListing and Transaction — have no live sync between them for these fields. This means a transaction can silently drift out of date (e.g., showing a stale list price) until an agent or TC manually notices and corrects it. Right now there's no visibility into the mismatch at all — it just sits wrong indefinitely. Proposed Solution: Detect drift automatically. When the linked MLSListing's price (or other key fields — status, closing-relevant dates) changes, compare it against the linked Transaction's corresponding field. Flag any mismatch. Don't auto-write blindly — verify first. A price change in the MLS should reflect a signed amendment (e.g., a listing price reduction amendment) somewhere in the file. Before auto-updating the Transaction record, the system should check whether that supporting document already exists (e.g., filed in SkySlope, or attached to the transaction). If the amendment already exists and is filed → auto-update the Transaction field with a note referencing the source document. Safe to sync automatically. If no supporting document is found → do NOT auto-update the field. Instead, generate a task: "MLS price changed to $X — upload the signed amendment or listing agreement update to confirm." This keeps the change visible and actionable without either silently applying an unverified number or silently ignoring it. This should extend beyond price. The same pattern applies to any Transaction field that should be backed by a document trail — status changes (e.g., MLS shows Pending but Transaction still shows Active), closing date changes, etc. Anywhere the MLS is the first place a change shows up, the Transaction should either sync-with-proof or flag-for-proof, never silently drift. Why this matters: This mirrors how a good transaction coordinator actually operates — they don't take the MLS at face value, but they also don't ignore it. They notice the discrepancy, verify it's backed by paperwork, and either reconcile the record or chase down the missing document. Right now, Brokerworks does neither: it neither notices nor asks. This creates a real compliance and accuracy gap, especially at scale, where stale fields can go unnoticed for weeks.

Danek Znika · Sep 11, 2026

Subject: Feature Request: Licensed County Property Data and PRC Retrieval Inside Brokerworks I’d like Brokerworks to provide property data and official Property Record Cards directly inside the app, without requiring Andy AI to search Zillow, Redfin, or the open web whenever information is missing. Also things a precursor to being able to accurately populate fields in forms we send. It eliminates agents making mistakes when copying and pasting the legal descriptions into listing docs for example. I have previously purchased countywide parcel data from Beacon in spreadsheet form. The Porter County file contained approximately 46,000 parcels and was purchased to identify multi-unit properties. That particular dataset is now several years old and stale, but it confirms that bulk parcel data is available for purchase or licensing. Recommended first step: Please contact Schneider Geospatial, which operates Beacon, and the appropriate Indiana county data custodians to determine what licensed access is available. Specifically ask about: • Current countywide parcel-data exports • Recurring spreadsheet or database updates • API access • SFTP or scheduled data delivery • Bulk PRC access • Permitted storage and internal application use • Licensing terms for AI-assisted property research • Coverage and pricing for Porter, Lake, LaPorte, Jasper, and Starke counties Preferred architecture: Brokerworks should maintain a normalized internal property-data layer populated from licensed county or county-authorized sources. A shared data model can support county-specific import adapters without forcing each county into a completely separate workflow. County data could be imported into an indexed internal database and refreshed on an agreed schedule. Brokerworks scripts could then retrieve property information by parcel number or normalized address with very few tool calls. Suggested internal tools for Andy AI: 1. Resolve county from an Indiana address or parcel number. 2. Search property by exact parcel number. 3. Search by normalized address when the parcel number is unknown. 4. Return structured assessor data from the internal database. 5. Retrieve or link to the official PRC when available. 6. Report the source, county, dataset date, and last refresh date. 7. Flag stale, missing, or conflicting records rather than guessing. 8. Filter properties by characteristics such as property class, unit count, acreage, assessed value, owner, township, or mailing address. The internal property record should include available fields such as: • Parcel number • Property address • Owner of record • Owner mailing address • County and township • Legal description • Acreage • Property class • Number of units • Year built • Building and land characteristics • Assessed values • Tax information • Transfer or sales history • Source system • Data effective date • Last internal refresh date • Official PRC link or stored original PRC Property Record Card workflow: When a user opens a property, lead, listing, or transaction, Brokerworks should be able to retrieve the official PRC from the county-authorized system. Parcel number should be the preferred search key because address searches can be unreliable. Before attaching a PRC, the system should verify multiple identifiers: • Parcel number • Street address • County and township • Legal description • Acreage The original assessor-generated PRC should be preserved rather than recreated from scraped webpage data. The record should also show where the document came from and when it was retrieved. Andy AI workflow: Andy should query Brokerworks’ internal property-data service first. Zillow, Redfin, and general web searches should not be the default source for basic property information. A reasonable source priority would be: 1. Licensed county or county-authorized parcel data 2. Official assessor or GIS system 3. Existing Brokerworks property and transaction records 4. MLS data, when permitted and applicable

Danek Znika · Sep 11, 2026