Help Center

Kit blueprints

A kit blueprint is a reusable definition for a physical kit. It describes the component types and quantities that normally belong together. The blueprint is not the asset itself; it is the pattern used to create or maintain assigned kit assets. This lets the company build many similar kits without rethinking the component list every time.

Use a blueprint when the warehouse treats the assembled group as a reusable unit. A camera kit, comms kit, small PA kit, or adapter case may all have predictable contents. The blueprint should define the normal contents, pricing behavior, and component expectations. If the normal kit changes permanently, update the blueprint. If one order needs an exception, change that order rather than rewriting the source pattern.

The blueprint is the promise of what the kit should be. That makes it useful for training, picking, inspections, and rebuilding a kit after something is replaced. If the blueprint says a kit has four adapters and the physical kit only has three, the mismatch should be resolved on the kit or the order instead of becoming an informal warehouse habit.

Assigned kits

An assigned kit is the physical inventory record created from a blueprint with specific component assets already attached. It can have its own Asset ID, warehouse, status, notes, and history. The kit rents as a unit, but Pluck still needs to know the components so picking, inspection, maintenance, and break-up decisions are understandable.

The important difference between a kit and a bundle is physical reality. A kit is a real assembled asset that can sit on a shelf, be scanned, be sent to maintenance, or be broken apart. A bundle is an order-building suggestion. If the gear lives together and gets tracked together, use a kit. If the gear is only suggested together when building an order, use bundled items.

Inventory item relationship views show whether a physical serialized item is assigned into a kit right now. Inventory type relationship views show kit blueprints that call for that type. Keep those separate: the blueprint says what a kit should contain, while item assignment says what this specific kit currently contains.

Open kits

Open kits are the kit mode for loadout-style warehouse groups. They start from a blueprint, keep their own kit identity and Asset ID, but do not lock exact serialized component assets ahead of time. A box of LED panels or a wagon of tables is the mental model: the warehouse knows what should be in the group, but the picker resolves the actual assets when the order is fulfilled.

Use assigned kits when the exact contents are already known and should travel together as one physical inventory record. Use open kits when the kit shape matters, but the exact serialized contents are intentionally chosen later. This keeps physical kit records honest without pretending an order prebuild or bundle is the same thing as warehouse inventory.

Maintenance and break-up

Kits need history because they change over time. Components may be replaced, removed, repaired, or temporarily substituted. When that happens, update the kit record so the next user can trust what the kit should contain. If the kit is broken apart, treat that as an intentional lifecycle action because it changes the relationship between the kit asset and its components.

During picking, a kit should communicate both the kit identity and any important component context. During returns, the team should verify that the kit came back as expected. During maintenance, the active maintenance job should be visible from item lists and history so a user does not try to reserve or pick a kit that is not ready.