Reference · built on requestOperator by FibricProperty & tenants

COI Expiry

Tracks vendor and tenant insurance certificates against what each contract requires, and proposes a reminder or a work hold at expiry.

Request accessPricing ↗

About

COI Expiry is an operator job for the certificates of insurance a property collects from vendors and tenants. It reads the register you keep, a Smartsheet sheet with vendor, coverage type, limit, and expiry columns, and the folder in Google Drive where certificates land. It reads vendors and the work orders assigned to them from Buildium or AppFolio, vendor records and open bills from Sage Intacct, and the insurance clause you record per lease.

Ahead of an expiry it proposes a reminder to the vendor or tenant naming what is required. At expiry with no new certificate it proposes a hold on that vendor's open work orders and a list for accounts payable. When a new file lands in the folder it proposes the register update for a person to confirm. Every approved change leaves a receipt.

This is a reference listing. It documents what Fibric would read from COI Expiry and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • A certificate register in Smartsheet: rows with vendor or tenant, carrier, coverage type, limit, and expiry, plus attachments on the row
  • Certificates as files: a Google Drive folder read through files.list and changes.list, with each file's name and modified time
  • Vendors and the work orders assigned to them: AppFolio work orders with VendorId; Buildium vendors and work orders
  • Vendor records and open bills in the ledger: Sage Intacct accounts-payable/vendor and bill, with vendor-total for balances
  • Leases that carry an insurance clause: Buildium leases and AppFolio occupancies, with the requirement recorded per lease
  • Contract requirements per vendor type: coverage, limits, and additional insured wording, as entered in the register or the configuration

Proposed actions

  • Target capability: propose a reminder to a vendor or tenant before expiry, naming the coverage required, sent through SendGrid mail/send on approval
  • Target capability: propose a hold on a lapsed vendor's open work orders: a Buildium or AppFolio work order update and a note with the reason
  • Target capability: propose a register row update when a new certificate lands in the folder, for a person to confirm after reading the file
  • Target capability: propose a list of vendors with open Sage Intacct bills and no current certificate, for accounts payable before the next payment run

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hold work to a vendor with a lapsed certificate

    The Smartsheet row for a vendor passes its expiry with no replacement. The operator proposes an on-hold update and a note on each open Buildium work order for that vendor, and the manager approves or grants a grace period.

    With Smartsheet, Buildium

  • Remind vendors before expiry

    Rows inside the reminder window are grouped by vendor. One SendGrid email each is proposed, naming the coverage and limit the contract requires, and the manager approves the batch.

    With Smartsheet, Twilio SendGrid

  • Catch a new certificate in Google Drive

    A file added to the certificates folder appears in changes.list. The operator matches it to a vendor by name and proposes the register update, which a person confirms after opening the file.

    With Google Drive, Smartsheet

  • Flag open bills with no coverage

    Vendors with open bills in Sage Intacct are checked against the register. Those without a current certificate are proposed as a list for accounts payable, with the amounts and the expiry dates.

    With Sage Intacct, Smartsheet

Requirements

  • A certificate register with an expiry column: a Smartsheet sheet the token can reach
  • A property connector with vendors and work orders: Buildium, or AppFolio on a plan with write access for holds
  • The requirement per vendor type or lease, entered in the register or the configuration
  • Optional: a Google Drive folder for incoming certificates, Sage Intacct for open bills, and Twilio SendGrid for reminders
Authentication
Runs on the connectors' own credentials. The register, the folder, and the vendor records are read, and reminders and holds proposed, within the access each connector was granted.

Limits

  • It reads expiry dates from the register, not from the certificate PDF. A person enters the date; the operator proposes the row
  • Requirements are yours. It does not judge whether a policy's wording satisfies a clause
  • A hold is a status change and a note on work orders in your property system. It stops no technician and blocks no payment
  • Tenant coverage is tracked only where a lease requirement is recorded. No insurer data is read

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request COI Expiry ↗

Questions and answers

What does the manager approve, and what can they change?
A reminder, a hold, or a register update. The proposal shows the vendor or tenant, the certificate on file with its expiry, the requirement it is measured against, and the work orders affected. Approve, extend a grace period, or decline.
What is recorded for each hold or reminder?
The register row and file that were read, the requirement applied, the reminder text or the hold as written, the approval with name and time, and the state of each work order before and after, so a hold can be lifted.
Does it read the certificate and decide on its own?
No. It reads dates and fields a person entered. When a new certificate arrives it proposes the update and waits for someone to read the file and confirm. Holds and reminders wait for approval too.
Ask about COI Expiry

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy