UpStream Custom Fields - WordPress Plugin

A Guide to Configuring UpStream Custom Fields

This guide to UpStream Custom Fields will help you decide what information your projects actually need, design a clear field scheme for your team and clients, assign fields to the right UpStream objects, and confirm that data is preserved during everyday use and CSV exchanges. Rather than run through a sales pitch or feature list, we’ll follow a practical path: from deciding what to ask to filling in a task, project, or bug report.

UpStream Custom Fields extends UpStream’s project model when its standard fields for name, status, due date, and assignee aren’t enough. For example, a web studio might need to record the browser, screen size, and reproduction environment for a bug, and the source, client priority, or internal code for a task. Instead of storing this information in free-form text, you can create dedicated fields and assign them to projects, milestones, tasks, bugs, or files.

Good configuration doesn’t start with adding as many fields as possible. It starts with three questions: who enters the value, who uses it to make a decision, and where should it appear? If you can’t answer any one of these questions, the field may end up blank, create extra work, and clutter the record. This guide explains how to distinguish a required working detail from information that belongs in a note or comment.

When Custom Fields Make Projects Easier to Manage

UpStream already has its own objects: projects, milestones, tasks, bugs, files, clients, and users. Custom Fields doesn’t replace that structure or create a second project management system. Think of it as a layer of specific details attached to an existing object. For example, a task’s status answers “What state is it in?” while the Request Channel field answers a different question: “Where did the work come from?” Combining these two purposes in one dropdown makes filtering less precise and leaves assignees unsure about what they should change.

The extension supports text fields, dropdowns, radio buttons, checkboxes, file uploads, color pickers, categories, tags, auto-increment fields, countries, and users. Don’t treat this list as a reason to create one field of every type. Choose a field type based on how the value will be used. If there are several possible values and they need to stay consistent, use a dropdown or radio buttons. If you need to group values, a category or tag may help. Use auto-increment when a number needs to be generated without manual input. A text field is best for a short fact that can’t be limited to a predefined list.

What UpStream Custom Fields Is Good For

The extension is especially useful when a team manages similar projects but needs to record the same kinds of details for each one. An agency might track the service type, test site domain, package of work, and client contact. A support team might record the device, browser, bug severity, reproduction steps, and attachment. A content team might need a category, editor, image rights status, and campaign code. The common thread is that each value is brief, needs to appear alongside the object, and may need to be compared or exported.

A field is also useful when people start treating a note like a form. If a manager keeps asking for “urgency, channel, segment, approval,” those details no longer belong in a free-form comment. Give each one its own short field and leave explanations in notes. That way, users see a set of clear controls instead of a paragraph with several hidden questions. Each field should capture one kind of decision. For example, don’t create a dropdown called Urgency and Reason: urgency helps prioritize the queue, while the reason is for analysis and discussion.

Who Benefits from the Extension, and Who Might Get Extra Work

UpStream Custom Fields can help a project manager standardize records, a support specialist collect diagnostic details, or a team whose clients regularly provide the same information. It’s useful when team members already use UpStream to work with tasks, bugs, or files, rather than just receiving status emails. Editors preparing an import can also benefit: a stable field slug can be used in a CSV header, making the data exchange more predictable.

The extension isn’t designed for complex forms with branching questions, calculations, payment steps, or long multi-page surveys. Don’t add a field just because “it might be useful someday”: empty columns teach people to ignore the form. If you only need the information once, at the start of a project, and it won’t affect later tasks, check whether a project description is enough. If a value changes daily and needs to trigger notifications or automation, first confirm that another UpStream feature supports the behavior you need. Don’t assume Custom Fields provides it.

Assign Data to the Right Object

A common design mistake is creating a project-level field when the value needs to be recorded for each task. Before you start, make a simple map. A project holds context that applies to the whole body of work: service type, client code, target market, or internal ID. A milestone holds a checkpoint detail: approval type, milestone owner, or color group. A task holds details about an action: channel, estimate, verification checkbox, or service category. A bug holds diagnostic information: device, browser, priority, or reproduction conditions. A file holds details about the material itself: source, version, rights status, or purpose.

This map matters more than the field names. A label like Priority could refer to a project, task, or bug, but those are different values. If the team doesn’t distinguish between these levels, an export may end up mixing values that can’t be compared. Start with the smallest useful set, run through one real work cycle, and only then add another field.

Design the Record Before You Design the Form

Before installing the extension, it helps to map one real use case on paper or in a test project. Consider a web studio that receives feedback from a client. A bug comes in by email or through a form, a manager records it in UpStream, an assignee reproduces the issue, and the client checks the fix. This workflow doesn’t need “every possible field.” It needs four clear ones: Environment, Browser, Screen Size, and Client Approved. The first three help reproduce the issue; the last distinguishes internal completion from client review.

For each candidate field, write down its purpose, who owns the value, the allowed answers, the object it belongs to, and how you’ll verify it. A browser needs a controlled set of answers, so a dropdown or radio buttons make sense. Screen size is often better as text, since the team may need to enter an exact value. Client approval can be a checkbox. This simple plan also shows why Client Comment doesn’t duplicate the other four: it belongs in the built-in notes or discussion, where longer text is appropriate.

Don’t try to turn every sentence in an internal policy into a field. A useful set of fields should be easier to fill in than to ignore. Before using real data, agree with the team on field names, allowed values, and who can change each field. That agreement, not the number of controls, makes the data reusable.

Prepare Your Site and Check the Extension

UpStream Custom Fields is an add-on for the main UpStream plugin, so first confirm that the core plugin is active and lets you create a test project. Don’t start with your live task database. Create a separate project with a neutral name, one task, and one bug. It will be easier to see where new fields appear and how they look on different object types.

Before uploading the archive, make a site backup using the method that’s standard for your hosting setup, and confirm that the administrator can access Plugins. The backup isn’t needed because configuration is inherently dangerous. It gives you a straightforward way to roll back if you choose the wrong labels, field types, or object assignments. You don’t need to edit WordPress core files, UpStream, or the extension during initial testing.

What to Check Before Adding the First Field

• A basic UpStream project opens. You can create or edit a project, task, or bug in the admin dashboard without system errors.
• Test user roles are available. An administrator and one user who will fill in a record or check it on the front end are enough.
• Someone owns the allowed values. One person should decide which dropdown values are allowed and when an outdated option should be removed or replaced.
• The data path is clear. If you may import from CSV later, record each field’s slug and each dropdown value, not just its display label.
• You have a short test case. For example: create a bug, select a browser, save it, reopen the record, and confirm the value is still there.

Discuss access separately. Custom Fields can hold useful work-related information, but it shouldn’t be used for passwords, payment data, personal documents, or other unnecessary personal information. If clients can access a project and some fields are intended for the team only, design them around your actual permissions model. UpStream offers an advanced permissions feature for finer control over individual fields, but don’t assume it’s enabled by default. Test access with a separate account first.

Install the Extension Without Mixing Up the Steps

In a standard WordPress installation, go to Plugins - Add New - Upload Plugin, select the extension’s ZIP archive, install it, and activate it. Keep the core UpStream plugin active: Custom Fields adds capabilities to its objects rather than replacing it. Don’t unpack the archive manually in a file editor or merge it into the main plugin’s folder. That makes updates harder and rollbacks less predictable.

After activating the extension, don’t create a dozen fields at once. Open the Projects menu in WordPress and look for Custom Fields. If it appears, create one test field. If it doesn’t, confirm that both components are active and that you’re in the same admin dashboard where UpStream appears. At this stage, a missing menu item is more likely to mean the extension wasn’t fully activated, the user lacks permission, or you’re looking under the standard Settings menu instead of a problem with the project data itself.

Run a Quick Check After Activation

Choose a simple field that’s easy to verify, such as a text field called Test Code for tasks. Click Add New Custom Field, choose Text, give the field a clear internal name, assign it to tasks, and save it. Next, open your test task, enter a short unique value, save the record, and close it. When you reopen it, the value should appear in the same field. This full cycle matters more than simply opening the field creation page: it checks the whole path from field configuration to object form to saving and reading the value again.

Verify the field: don’t consider the extension configured until you save and reopen at least one object. A field appearing in the list doesn’t prove that it’s assigned to the right object type or that your team can use it.

After the test succeeds, delete the test field or rename it for real use only if its type and assignment match the approved field map. If you tried a different field type, it’s safer to delete the draft and create the actual field from scratch. That keeps the field list clear and prevents internal test names from appearing in exports or staff instructions later.

Choose Field Types That Keep Data Clear

A field type affects more than appearance: it also affects how easy the data is to work with. People enter information in the way the interface allows. Free text leads to inconsistent wording, a dropdown keeps answers consistent, and a checkbox records whether a condition is present. So instead of asking, “Which control looks more familiar?” ask, “What kind of value will we need when we check, sort, or import this data later?”

Text, Dropdowns, and Radio Buttons

Use text for short, unique details: a client report number, mockup version, exact screen resolution, or test branch name. Don’t use it for a status, country, or department if you’ll need to compare those values later. In a free-text field, one person might enter “Chrome,” another “Google Chrome,” and a third might add a version number. A dropdown works better for a set of small, known choices. It saves space in the form and reduces the risk of inconsistent wording.

Radio buttons are useful when there are only a few choices and you want each one visible at a glance. For example, a mockup check might offer Desktop, Tablet, and Phone, without turning the form into a long list of devices. Checkboxes work for independent conditions that can apply at the same time: “attachment included,” “client review required,” or “reproduces on the staging site.” If choices are mutually exclusive, don’t represent them with several checkboxes; that can create contradictory records.

Categories, Tags, and Color

Categories and tags are useful when your team needs to group projects or child objects using its own UpStream vocabulary. These groups don’t have to match the categories and tags used by regular WordPress posts. For tasks, you could create project tags such as design, content, and integration and use them to classify work. A category is better for a stable hierarchy, while tags work well for flexible, overlapping attributes. Don’t represent the same idea with both field types.

Use a color picker only when color is part of the data, not just a decorative touch on the record. For example, an agency might store an approved campaign color or brand color. For priority or status, use UpStream’s built-in features, which already have their own display behavior. Without clear guidance, people may interpret a color differently, and color alone won’t help manage the queue.

Files, Users, Countries, and Auto-Increment Fields

A file field is for an attachment that belongs to a specific object, such as a bug screenshot, supporting document, or source file. It doesn’t replace the project’s shared files area. A user field lets you select a WordPress user, but keep in mind that imports use the user ID, not the user’s email address or login. A country field uses a predefined list and may allow multiple selections if that option is enabled in its settings.

Use auto-increment when your team needs a sequential number for new objects. It doesn’t replace a WordPress internal ID and isn’t meant to provide a “pretty” number that staff will edit manually. Its value is consistency: each record gets a number automatically, and the field is there to be read. Use it only when a sequence is genuinely needed for reporting, client communication, or matching external documents.

Configure Field Names, Choices, Assignments, and Visibility

The field creation screen handles four separate tasks: giving users a clear label, setting a technical slug, limiting the allowed values, and choosing which objects will display the field. Don’t work through these steps on autopilot. Changing a label later is usually simple, while changing a slug or the structure of a dropdown can affect imports and existing records. Configure the field on a test object first, then record the naming convention in your team’s working guidelines.

Give Each Field a Short Name with One Meaning

A field name should ask for a specific value, not describe an entire process. Good examples include Browser, Request Source, Campaign Code, and Client Approved. Avoid vague labels such as Additional Information, For Manager, and Required: they don’t tell users what to enter or when. If a field is required for your process, explain that in the instructions and use a clear review step instead of turning the field name into a warning.

Avoid confusing pairs such as Client Status and Status for Client, or Type and Task Type. In a few months, no one may remember the difference. Name a field for its subject and level instead: Project Segment, Task Channel, or Bug Severity. The label may be a little longer, but it helps prevent mistakes.

Choose a Slug Deliberately

A slug isn’t a display label; it’s the stable identifier used to reference a field during data exchange. In a CSV file, it becomes part of the column header: for a task field with the slug country-check, use the column task.country-check. Choose the slug before the first import, and don’t include temporary labels such as new, a sprint number, or an employee’s name. Short English words separated by hyphens work well: source-channel, client-approved, and screen-size.

The technical name doesn’t have to match the display label exactly. You could pair the label Client Approved with the slug client-approved. The key is not to change it without a migration plan. If you already export or import data, a new column with a different slug won’t automatically rename the old one. First test the import in a project set aside for testing, confirm that the target field is populated, and only then apply the mapping to your live data.

Set Up Dropdown Choices

For each choice, decide in advance whether it’s a user-facing label, a technical value, or both. CSV imports for dropdown fields use the value, not the display label. If your team doesn’t need a separate machine-readable value, the safest starting point is to make them the same. For example, use desktop as both the value and the display label. If an integration requires a fixed English code, keep it separate and explain that staff should select the human-readable option rather than enter the code manually.

A dropdown shouldn’t be so long that a text field would be easier. If you keep having to add new choices, consider whether tags, a category, or a free-text value would work better. If the list is short, don’t add an Other option unless users have a way to explain it. Otherwise, the most important records may end up in an unexplained catch-all. If necessary, pair a controlled dropdown with a separate text field called Explanation, but only if the team will actually read both.

Assign Fields to Projects, Milestones, Tasks, Bugs, and Files

After choosing a field type, assign the field to one or more UpStream objects. This isn’t a cosmetic option; it determines where the data belongs. A field assigned to a project won’t automatically appear on every task. Likewise, a task detail doesn’t become a project-wide attribute. Don’t try to work around this by creating one field “for everything”: users won’t know why the same label means different things on a project and a bug.

Projects: Context Shared Across the Work

Use Projects for details that frame the whole body of work: service category, internal contract ID, market, client contact, or reporting requirements. These values help people understand a project without reading every task. Don’t put details here that change with each fix, such as the browser, test device, or specific request channel. A changing value will either become outdated or force someone to rewrite the project-wide context to account for one particular case.

Milestones: Checkpoints, Not a Second Task List

Milestones work well for details associated with a major checkpoint: approval type, funding stage, acceptance owner, or editorial package. Avoid tracking minor details here. If a milestone needs ten fields, you may be trying to run a separate process inside one checkpoint. Move day-to-day details to tasks and keep only the information that helps assess the readiness of the milestone’s work.

Tasks: Details That Help Someone Take Action

Tasks usually need the most practical field set: work category, source, ready-for-review checkbox, mockup code, brief estimate, or assigned user profile. Before adding a field, look at the task as an assignee would. Will the answer help them start, hand off, or check the work? If not, the field may belong on the project or in the discussion instead. A good task has enough context to support an action without duplicating the client’s entire intake form.

Bugs and Files: Keep Diagnostic Details with the Evidence

A custom bug field is especially useful when it affects whether someone can reproduce the issue: browser, device, resolution, environment, impact, or a retest check. Don’t use these fields instead of the bug description. Keep the steps, expected behavior, and actual behavior in the description, and use fields to structure details that recur across reports. For Files, you might store the material type, source, approval status, or purpose. Use a file field for an attachment linked to a specific record; don’t split up the project’s shared materials unless necessary.

Front-End Visibility and Client Collaboration

Custom Fields can be used in the admin dashboard. To make them available on the front end, pair them with UpStream Frontend Edit. This is an important limitation: installing Custom Fields alone doesn’t turn a project into an editable client intake form. If clients need to add or edit records on the site, plan the permissions, test role, and field set first. Don’t enable editing across the whole form just because it would be convenient to collect a few details outside the admin dashboard.

Start with read-only access. Create a test client account, open a test project, and see which details the client actually needs to review. Then decide separately what they can edit. If a client reports a bug, the browser and screen size may be useful fields. If the record includes an internal code or team estimate, keep those details for staff. If you need fine-grained control over individual fields, test the advanced permissions on a site copy: the available access may depend on the user’s role, assignee, author, client status, and the specific project.

Don’t replace a clear form with a complicated set of hidden rules. Users should see only fields whose purpose they understand. Before launch, ask two people to complete a test operation: one creates a record and the other reviews it. If they interpret the choices differently or can’t find a field, the problem is in the data model, not user discipline. Fix the label, list, or assignment before records accumulate.

How to Roll Back a Field That Isn’t Working

If a new field turns out to be unnecessary, first remove it from the instructions and replace it with a clearer process. Then export any data you need to keep for historical reference before deleting the field or retiring it from active use. Don’t remove a field in the middle of a review without warning: an assignee may see the changed record and assume the requirement was canceled. If a dropdown has become unwieldy, it may be safer to create a new field with a clear set of choices, test the transfer of relevant values, and keep the old field until you’ve finished checking the data.

Practical Example: A Bug Record for a Web Project

Let’s build a working example for an agency that maintains a client website, rather than an abstract set of fields. The goal is for a manager to collect enough information to hand off the work, for a developer to reproduce the issue without several rounds of messages, and for the client to confirm the fix. UpStream already has a bug object, description, assignee, status, and file. Custom Fields will add only the repeatable details that can’t be reliably extracted from free-form text.

Define and Prepare the Workflow

Create a test project called Client Website Update, add one bug, and prepare two test users: a manager and an assignee. Before creating fields, write down the expected workflow: the manager reports the bug and records its environment and browser, attaches a screenshot if needed, and the assignee reproduces the issue and updates the standard status. The manager then marks the internal review, and the client confirms the fix. This sequence deliberately separates project status from diagnostic details.

Five fields are enough for this example. Use a dropdown for Environment with the values production, staging, and local and clear display labels. Use a dropdown or radio buttons for Browser. Use text for Screen Size. Add checkboxes for Reproduced and Client Approved. If the team needs to attach a screenshot directly to the bug, add a file field. If screenshots are usually stored in the shared project files area, don’t create a duplicate.

Step 1: Create the Fields and Assign Them to Bugs

1. Go to Projects - Custom Fields and select Add New Custom Field.
2. Create an Environment dropdown with the slug environment. Add only the options the team actually uses and assign the field to Bugs.
3. Create a dropdown or radio buttons for Browser with the slug browser. Don’t include screen size or device type; those are separate answers.
4. Create a text field called Screen Size with the slug screen-size. Set a short format in the team instructions, such as 1440x900.
5. Create the Reproduced and Client Approved checkboxes with clear slug values. Save each field and make sure it’s assigned to bugs, not projects or tasks.

You don’t need to reopen the bug record after every step. Once all the fields are ready, create one test bug. If some fields are missing, don’t create duplicates. Go back to the relevant field and check that it’s assigned to Bugs. Duplicate fields with similar names are a common source of confusion in later exports.

Step 2: Fill In a Bug Report as a Manager Would

In the bug description, include the reproduction steps and expected behavior. For example: “On the contact page, open the form, enter a name, and click Submit. The expected behavior is a success message; instead, the form doesn’t respond.” Then select production, choose the appropriate browser, enter 1440x900, and check Reproduced only if the manager has actually repeated the issue. Don’t use the checkbox to record an assumption. If the client supplied the information and no one has tested it yet, leave the box unchecked so the assignee knows reproduction is part of the task.

Attach a file only when it adds useful context, such as an error screenshot, short video, or source file. Don’t store multiple copies of the same evidence in both a field and the comments. Agree on one place where the key attachment should live. If the record contains several files, note in the description which one relates to the report; a correctly configured file field won’t solve the problem if no one can identify the right attachment.

Step 3: Hand Off the Record and Check Roles

The assignee opens the bug and reads the structured details first: environment, browser, screen size, and whether the issue has been reproduced. They can then use the description as a set of instructions. Don’t turn Client Approved into an alternative status. The developer can update the standard status according to the team’s process, while client approval remains a separate fact. That lets the manager track two different things: whether the technical work is complete and whether the client has accepted it.

If the bug can’t be reproduced, don’t clear the original details. Add a note saying which environment and steps you checked, and leave Reproduced in the state defined by your team’s rule. The label needs one consistent meaning: either “confirmed during initial review” or “reproduces right now.” Don’t use it to mean both. For the second meaning, create a separate field or use a status if it fits the existing process.

How a Field Affects the Data: From Entry to Verification

Custom Fields follows a simple, observable sequence. First, an administrator defines a field and assigns it to an object type. Then a user opens a specific project, task, bug, or file and sees the fields assigned to it. After the user saves a value, it becomes part of that record. When someone opens the record again, the value should appear as a separate detail instead of being buried in the description. That’s the key difference from a free-form note: the question, answer format, and place for the answer are defined in advance.

In WordPress, UpStream projects are associated with posts and their metadata, so there’s no need to edit the database manually to store a custom field value. Editing database tables by hand can damage serialized project data and make problems difficult to diagnose. Use the UpStream form or CSV import. Use an API only if you understand the access model and have tested the operation on a site copy.

Input, Assignment, Saved Value, and Display

Input is the field you create and the value a user selects. Assignment is the object or objects the field belongs to, along with its field type. Saved value is the information stored on a specific record. Display is the value shown when the record is reopened, in the assigned part of the project, or in an export. If a field isn’t visible, don’t assume the cause is caching. Check the sequence from left to right: is the component active, is the field assigned to the right object, was the object saved after the change, and can the current user see that part of the record?

This way of checking the setup avoids making assumptions about the extension’s internal implementation. The key point for users is simple: a “global project field” won’t automatically apply to every task. What you see depends on the field type, its assignment, and the object where it was saved. So test every new field on the object type selected in its settings. A task field can appear correctly in the Custom Fields list without appearing on a bug; that’s expected behavior, not a failure.

Verify Data After Each Change

After creating or changing a field, run a quick five-step check. Create a fresh test object of the right type. Select or enter a value. Save the record. Reopen it under the same role. Then sign in as the role that will use the object in practice and check what that user can see. This takes less time than fixing ten records after users have selected the wrong field or missed one they need.

For a dropdown, check that the choices stay consistent: select a value, save the record, and confirm it appears with the same label when you reopen it. For a user field, confirm that you selected the intended WordPress user. For a file field, check both the upload and whether the intended role can open the file. For auto-increment, confirm that the number is generated automatically and that staff don’t try to enter it manually instead of letting the extension assign it.

Test Front-End Access Without Using Live Data

If clients will edit records, test that process separately from the admin dashboard. Enable UpStream Frontend Edit only for a use case that needs it, create a separate test account, and check one operation: open a project, add or edit an allowed object, save it, and confirm the update appears. Then test the opposite case: the client shouldn’t be able to change an internal field. This contrast matters more than a polished interface because it shows where responsibilities begin and end.

Don’t enable front-end editing at the same time as a bulk import of old data. Start with one role and one object type, collect feedback, and then expand. If users misunderstand a field, revisit the data model. The problem is often solved by changing the name, limiting the choices, or moving the field to another level, rather than adding another instruction.

CSV Import and Export: Keep the slug and Value Aligned

CSV is useful for importing similar projects, tasks, bugs, or files from a prepared spreadsheet. It doesn’t replace field configuration: Custom Fields must already exist in UpStream, use the right slug, and be assigned to the right object. Only then can a CSV column populate the field. Import isn’t a good way to create a data structure on the fly before your team has agreed on it.

A column header is made up of the object type and the field slug. For a task field with the slug country-check, use the header task.country-check. For a dropdown, import the value rather than the display label. This distinction often explains why an import completes but the field stays blank or shows an unexpected value. If there’s no technical need to separate the label from the value, keeping them the same is easier to maintain. If you need separate values, keep a mapping table with the CSV template.

Test a Small Import Before Loading a Larger File

Create one test project and one row for the object type you need. Include the standard UpStream data the import requires and just one Custom Fields column. Start with a text field, then try a dropdown, and then a user or country field if those types are part of the import. Testing in this order helps you separate a header problem from an invalid value. Don’t begin with a file containing hundreds of live rows: a single wrong slug or dropdown value can create hours of manual reconciliation.

task.title,task.environment,task.browser,task.screen-size
Test the form,production,chrome,1440x900

This isn’t a universal import template; it’s a short example of how field names work. Here, environment, browser, and screen-size must exactly match the slug values of the fields already created for tasks. Before importing real data, confirm that production is an allowed value in the selected dropdown. If your display label is in another language, don’t substitute it for the technical value without testing first.

Import Requirements for Specific Field Types

User fields require a WordPress user ID during import, not an email address or login. This makes the assignment unambiguous, but it means you’ll need to prepare a mapping table in advance. Country fields use a three-letter country code as the value. Standard object statuses must also match their settings exactly. These requirements help prevent inconsistent entries such as “United States,” “US,” and “USA” appearing in the same column.

After a test import, open the target record in UpStream instead of relying only on the import completion message. Check four things: the object was found or created, the field is assigned to the right level, the value appears as expected, and the dropdown displays a clear label. If any of these checks fail, stop the bulk import. Fix the template, remove or isolate the test records according to your environment’s rules, and test again with a new row.

Use Exports to Check Data Quality, Not Just as an Archive

UpStream can export milestones, tasks, bugs, and files as text or CSV. Use exports not only to move data into another program, but also to check what people have entered. Export a small test set, open it in a spreadsheet, and compare it with the records. Confirm that each object’s field appears in the expected column and that dropdown values are consistent. If the data is messy, the cause is often a free-text field or a lack of clear instructions for the team.

An export can also help when you need to update a dropdown. Say you want to replace other with several clearer channels. First export the records and review real examples. Then approve the new values and plan the migration. Don’t rename a choice in the middle of active work without checking: some people may keep using the old wording, and the history may become harder to interpret. Review the data, update the choices, and run a short check.

Pair UpStream Custom Fields with Frontend Edit and Permissions

When people outside the team enter data, pairing Custom Fields with UpStream Frontend Edit can be useful. Frontend Edit lets signed-in users work with tasks, bugs, files, and discussions on the project’s front end. Custom Fields defines which additional details the form needs, but it doesn’t determine who can change them. These are two separate configuration tasks: choose the fields and verify access for each role.

Keep Client Forms Focused on the Details They Need to Provide

Clients rarely need the full administrative record. For a bug report, environment, browser, screen size, and evidence may be enough if those details help resolve the issue. For a task created by a client, you might ask for the request category, preferred date, and a link to the relevant material, but not an internal estimate code. The fewer fields without a clear purpose, the more likely it is that the first request will be complete.

Start with one project and one client account. Ask the client to perform a typical task without guidance: create a record, select an option, attach a file if needed, and save it. Then sign in as a manager and check that the data appears where the team expects it. If the client sees an internal field or can’t save the record, don’t try to fix it with an email instruction. Adjust the fields, visibility, or permissions before rolling out the setup more broadly.

Distinguish Field Access from Project Access

UpStream has manager, user, and client user roles. Advanced permissions can also make individual fields hidden, read-only, or editable. But don’t assume that a new process is “secure by default.” First decide whether the user should be able to see the project at all, then check how each sensitive field appears for that role. An internal note doesn’t become secure just because its label includes the word “internal.”

Files need particular attention when external users are involved. Before launch, confirm that the intended role can access a test file and that it isn’t exposed to anyone else. Don’t use Custom Fields for credentials or documents that belong in a dedicated secure storage system. A project record should contain the details needed to do the work, not everything a client has ever sent.

Make a Small Front-End Table Adjustment Without Editing Plugin Files

After setting up the fields, a team may decide that a column in the front-end task or bug table should be hidden so a useful custom field doesn’t get lost among less important details. You can override UpStream’s styling with CSS in your theme. Avoid editing the plugin’s own CSS files, and inspect the selector on a test page before applying a change.

The example below hides the standard milestone column only in the front-end task table. Add it where your theme or child theme is meant to hold custom CSS. Test it on a site copy first: if the team relies on the milestone column, don’t hide it just to make the table more compact.

/* Example: hide the milestone column only in the UpStream front-end task table */
body.upstream-front-end table#tasks th[data-column="milestone"],
body.upstream-front-end table#tasks td[data-column="milestone"] {
  display: none;
}

After saving, open the public project in a regular browser window and a narrow one. Confirm that the remaining column headings line up with their cells and that the manager can still see the milestone in the admin dashboard. To undo the change, remove this block from your custom CSS and clear the regular site cache if you use one. Don’t edit UpStream styles directly: an update will overwrite the change and make it harder to diagnose a problem if the table changes.

Verify the Setup Before Using It on Live Projects

Once the fields are created and you’ve tested the workflow, run a short acceptance check. The goal isn’t to explore every possible interface variation; it’s to confirm that the new data model supports real work. Choose one test project, task, bug, and file. Fill in only the fields assigned to each object type. Save the records, reopen them, and check the view as an administrator and, if applicable, as a regular team member or client.

Then check the configuration itself. Open Custom Fields and match each active label to its recorded slug, object, and type. For each dropdown, verify that all allowed values exist. For an import, create one CSV row and confirm that the record receives the right value. For the front end, confirm that users can edit only the permitted fields. This check makes the setup repeatable instead of leaving it as a series of one-off admin clicks.

Project Manager’s Checklist

• Each field has an owner. Someone is responsible for approving the choices and keeping them current.
• Each field supports one decision. It doesn’t combine unrelated questions that need to be filtered differently.
• Assignment has been tested on the object. No one expects a project field on a task or looks for a bug detail at the project level.
• The slug is recorded before a CSV exchange. You know the exact column header and technical dropdown value to use for an import.
• Roles have been checked separately. Users and clients see only the data and controls they need.
• There’s a rollback plan. The team knows how to restore the previous form or remove a field without losing useful history.

In short: Custom Fields is working when you can complete the full cycle on one object: create a field, enter a value, save the record, reopen it, check access by role, and export the data if needed.

When UpStream Custom Fields Is a Good Fit

The extension is most useful when your team already uses UpStream for projects, milestones, tasks, bugs, and files but needs a few more consistent details. Start with one repeatable workflow, give each field a single purpose, record its slug before exchanging data, and verify it on a test record. That approach gives the team a clear system that supports action instead of a long form.

If you’ve mapped the fields, checked the roles, and tested saving and reopening a record, you can download UpStream Custom Fields and apply the setup to one real project. First see how the team uses the fields, then add only those that help people make decisions, reproduce issues, or confirm work.