Designing Work Items for Global Trade: A Project Manager's Guide

Why Your Import/Export Team Needs a Work Item Model

When you run an import/export operation, you're juggling purchase orders, shipping containers, customs declarations, and compliance checks. Each of these is a type of work item—a discrete unit of work that needs to be tracked, assigned, and completed. But if you just create a generic "task" list, you'll miss the nuances of international trade.

Take a customs clearance process. When a shipment arrives, your broker needs to submit documents, pay duties, and get clearance. The work item isn't just "clear customs." It has fields like HS code, country of origin, and invoice value. It has a workflow: from "submitted" to "under review" to "cleared." And it has rules: if the shipment is over a certain value, it requires an additional inspection.

In this article, I'll walk through how to design a work item model for an import/export project management tool, drawing on lessons from software design but applying them to trade operations.

Start with the Six Questions

Every work item—whether it's a shipment, a customs declaration, or a supplier order—must answer six questions:

• What is it? The type of work item (e.g., Shipment, Customs Declaration, Supplier Order).
• What data does it hold? The attributes: tracking number, port, HS code, value, etc.
• How do users interact with it? The forms and views: create, edit, list, detail.
• How can it change? The workflow: statuses like "Draft," "In Transit," "Cleared," "Delivered" and the transitions between them.
• How does it connect to other items? Relationships: a shipment links to a purchase order and to a customs declaration.
• Where do these rules apply? The scope: which team, region, or product line uses this type.

Separating these concerns is crucial. If you mix them together, you end up with a giant configuration table that's impossible to maintain. For instance, the "status" of a shipment might be "In Transit" for one team, but another team might call it "On the Water." Those are the same status, just different labels. If you embed the label in the type, you can't reuse the type.

Define Types That Fit Trade Operations

A work item type is the stable identity of an object. It's not just a label. For import/export, you might have types like:

• Import Shipment
• Export Shipment
• Customs Entry
• Supplier Invoice
• Compliance Check

Each type has a name, an icon, and a description. But it shouldn't own attributes like "default owner." Why? Because the same type might be used by different teams with different rules. For example, an "Import Shipment" might have a default owner of the logistics coordinator in one team, but the customs broker in another. If you bake the default owner into the type, you can't reuse it.

Instead, the type should just define what the object is. The attributes (like owner) are separate. The workflow is separate. The forms are separate.

Attributes: More Than Just Fields

In import/export, attributes are critical. You need to track not just a text field for "container number," but also complex data like:

• Person: who is responsible for the shipment?
• Attachment: bill of lading, commercial invoice, packing list.
• Enum: incoterms (EXW, FOB, CIF, etc.), port of loading, port of discharge.
• Calculated: total value = sum of line items, or days in transit = current date - departure date.

A good attribute model treats everything as an attribute. That means you can reuse attributes across types. For example, "HS Code" is an attribute that appears on both an Import Shipment and a Customs Entry. You define it once, and let both types use it.

But be careful: don't just create a "custom field" with a type. You need to define the data type, allowed values, whether it's required, and how it's validated. For instance, the "Incoterm" field should be a dropdown with specific values, and it's required on every shipment. If you make it a free text field, you'll get inconsistent data.

Scope: Global vs. Local Attributes

In a global trade system, you might have attributes that are used across the entire organization, like "HS Code" or "Country of Origin." These should be global. But you'll also have local attributes, like "Customs Broker" or "Bonded Warehouse," that only apply to a specific team or region.

You need to decide where to store these attributes. If you have a global attribute that's used everywhere, define it once and let everyone use it. If it's local, define it in the space (or project) that needs it. But avoid duplicating attributes with the same name but different meanings. For instance, "Port" might mean "port of loading" in one team and "port of discharge" in another. Those are different attributes, even if they have the same name.

A good rule of thumb: if two attributes have the same value and can be compared in a report, they should be the same attribute. If not, keep them separate.

Design Forms That Help Users, Not Hinder Them

Forms are how users interact with your work items. When you create a new shipment, what fields should you show? You don't want to show every field at once—that's overwhelming. Instead, show the essential fields first: shipment number, origin, destination, and expected date. Then let users fill in more details later.

For example, the "customs value" might be required before you can submit a customs entry, but it's not needed when you first create the shipment. So you can make it required only at the "Submit Customs" step, not at the "Create Shipment" step.

Also, think about the layout. On the detail page, you want to show the current status, who's responsible, and what actions are available. On the edit page, you want to group related fields, like "Shipping Info" and "Customs Info."

Workflows: The Heart of the System

Workflows define how a work item moves from one status to another. For an import shipment, the workflow might be:

Draft → In Transit → Customs Clearance → Delivered

But each transition can have rules. For example, to move from "Customs Clearance" to "Delivered," you must provide the customs clearance certificate. That's a required attachment. You might also require that the "Customs Value" field is filled in.

Workflows should be separate from the type. You can define a workflow for "Import Shipment" and reuse it for "Export Shipment" if the steps are the same. Or you can have different workflows for different regions, because customs procedures vary.

One important thing: don't let users just change the status arbitrarily. Use transitions. A transition is a specific action that moves the item from one status to another, and it can have conditions, permissions, and post-actions (like sending a notification).

Relationships: Connecting the Dots

In import/export, work items are highly interconnected. A shipment might be linked to a purchase order, a customs entry, and an invoice. You need to model these relationships.

There are two main types: hierarchical (parent-child) and associative. A purchase order can have multiple line items, but that's not the same as a shipment being linked to a customs entry. The latter is an associative relationship with a specific meaning: "this shipment requires this customs entry."

When you define a relationship, think about its semantics. Is it directional? Does it affect calculations? For example, if you link a shipment to a customs entry, you might want to show the total duties paid on the shipment. If you link a shipment to a purchase order, you might want to show the total value of goods.

Relationships also affect permissions. If a user has access to the shipment, do they also have access to the linked customs entry? Probably not, if the customs entry is handled by a different team.

Configuration Changes Are Risky

When you change a field from optional to required, you might break existing processes. For example, if you make "HS Code" required on all shipments, but some old shipments don't have it, they'll fail validation. So you need to handle configuration changes carefully.

Use a versioning system. When you change a workflow, don't immediately apply it to all existing work items. Instead, let new work items use the new version, and let existing ones continue with the old version until they're closed. Or, you might want to migrate them, but that's a data migration project.

Also, before you delete a status or a field, check if any existing work items are using it. If so, you need to either migrate them or block the deletion.

Putting It All Together: A Practical Example

Let's say you're building a system for a freight forwarder. You have a work item type called "Shipment." It has attributes like Container Number, Port of Loading, Port of Discharge, and Expected Arrival Date. The workflow is: Draft → Booked → In Transit → Customs Clearance → Delivered.

You also have a type called "Customs Entry." It has attributes like HS Code, Value, and Duty Amount. The workflow is: Draft → Submitted → Under Review → Cleared.

These two types are linked: a Shipment can have multiple Customs Entries (one per product type, maybe). When a Customs Entry is cleared, you might want to update the Shipment's status to "Customs Clearance Done." That's a relationship with a post-action.

You can also have dashboards that show all shipments in transit, or all customs entries pending review. Because you have a clean model, you can query across types.

Conclusion: The Model Is the Foundation

Designing a work item model for import/export isn't about creating a bunch of fields. It's about creating a flexible system that can adapt to different teams, regions, and processes. By separating types, attributes, workflows, layouts, relationships, and scope, you build a platform that scales. And when you get it right, your team can focus on moving goods, not on fighting the software.