Reference · built on requestOperator by FibricProperty & tenants

Package Overflow

Watches package room and locker load against delivery peaks and proposes reminder waves, overflow shelving, or a returns list.

Request accessPricing ↗

About

Package Overflow is an operator job for buildings where parcels arrive faster than residents collect them. It reads the packages logged in your property system, such as Entrata parcel alerts, or a package log you keep in Airtable, and the carrier entries recorded by a ButterflyMX intercom. It reads the public holidays for each property's country from Nager.Date, since the days around them are when volume climbs.

When the room or locker bank nears the capacity you set, or a package has sat past your hold period, it proposes one of three things for the manager to approve: a reminder wave to the residents concerned, an overflow period with the extra shelving to open, or a list of packages to return to the carrier. Each approved proposal is carried out once and leaves a receipt.

This is a reference listing. It documents what Fibric would read from Package Overflow 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

  • Parcel alerts per property from Entrata's getParcelAlerts, with the unit and the date each package was logged
  • A package log you keep: an Airtable table with unit, carrier, logged date, and picked-up date, read by view
  • Carrier entries at the door: ButterflyMX access logs with entry_method and logged_at, and delivery pass keychains in use
  • Public holidays by country and year from Nager.Date, including the regional ones flagged by county
  • Delivery and bounce events for reminders already sent, from the SendGrid Event Webhook or Twilio message status
  • Room and locker capacity, the hold period, and the reminder cadence, as you set them in the operator's configuration

Proposed actions

  • Target capability: propose a reminder wave to residents whose packages have passed the hold period: one SendGrid email or Twilio SMS each
  • Target capability: propose an overflow period when logged packages approach the capacity you set: the dates, the shelving to open, and a staff notice
  • Target capability: propose a returns list of packages past the return limit, with each resident's reminder history, approved before any package leaves
  • Target capability: propose a delivery pass window for a carrier ahead of a holiday peak, through ButterflyMX POST /v4/keychains/delivery_pass

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

What you can build

  • Send a reminder wave after a holiday weekend

    Entrata parcel alerts older than the hold period are grouped by unit. The day after a Nager.Date holiday, the operator proposes one SendGrid email per resident, and the manager approves the wave or removes names.

    With Entrata, Twilio SendGrid, Holidays & FX Reference

  • Open a delivery pass before a peak

    Where ButterflyMX access logs show carrier entries climbing in the days before a holiday, the operator proposes a delivery pass keychain for the carrier and the window it covers.

    With ButterflyMX, Holidays & FX Reference

  • Run from a package log in Airtable

    An Airtable view of packages without a picked-up date is read each day. Past the hold period, the operator proposes a Twilio SMS per unit; past the return limit, a returns list.

    With Airtable, Twilio

  • Propose returns for unclaimed packages

    Packages past the return limit are listed with their reminder history and the Twilio delivery status of each message. The manager approves the list, and staff hand the packages to the carrier.

    With Entrata, Twilio

Requirements

  • A source of logged packages: Entrata parcel alerts, or an Airtable table with unit, carrier, logged date, and picked-up date
  • A messaging connector for reminders: Twilio SendGrid for email or Twilio for SMS, with a sender you have set up
  • The capacity of each package room or locker bank, the hold period, and the return limit, entered in the configuration
  • Optional: ButterflyMX for carrier entries and delivery passes, and Nager.Date for the holiday calendar of each property's country
Authentication
Holds no credentials of its own. Parcel records, door logs, and holiday dates are read, and reminders and passes proposed, through the connectors you bind, each with the access you granted it.

Limits

  • No package locker connector is in the catalog. Fibric links your locker platform on request; until then occupancy comes from logged packages, not locker sensors
  • It counts packages as staff logged them. A parcel never entered is invisible, and one never marked collected reads as still on the shelf
  • It reads holiday dates as a marker for peaks. Carrier volume forecasts are not read
  • It does not open a locker, hand a package back, or contact a carrier. Returns are a list for a person

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 Package Overflow ↗

Questions and answers

What does the manager approve?
A wave, an overflow period, or a returns list. Each shows the packages behind it, the residents or staff it reaches, and the message text. The manager approves, trims the list, or declines. Nothing is sent and nothing moves until then.
What record is left?
The packages counted and the alerts or rows they came from, the threshold crossed, the proposal, the approval with name and time, and each message as the connector accepted it, with its delivery status once known.
Does it ever text a resident or return a package on its own?
No. Every reminder waits for approval, and a returns list is a list. A person hands packages to the carrier and marks them in the log. The operator proposes; it does not act at the shelf.
Ask about Package Overflow

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