## Overview
Custom fields are used when your team needs to capture business information that is not already available on a Pams form, such as an additional detail needed for a Sales Job, Product, Project, Account, Principal, or another supported area. An administrator opens **Configuration > Custom fields**, creates the field, sets the available details such as **Name**, **Description**, **Display Order**, **Default**, and **Active**, then saves the entry. The final outcome is a clear, usable field on the intended supported Pams form, where users can enter the additional information consistently during their daily workflow.

## Trigger: [What starts this process]
Start this process when a team identifies information that must be captured consistently but does not have an existing field on the relevant Pams form. This often happens when sales, purchasing, project, finance, or warehouse teams begin tracking a new commercial requirement, customer requirement, tender detail, product attribute, or internal reporting detail.

Before opening **Custom fields**, agree on the exact business purpose of the information. Ask the person requesting the field where users need to see it, when they need to complete it, and who will use the information afterward. For example, a field requested for Sales Jobs should support a real sales activity such as preparing an Offer, following up on an Inquiry, confirming a Orders, or reviewing Booking results. A field requested for Products should support work performed from the **Products** screen rather than duplicate information already held in Product Categories, Product Types, or Product Variants.

Use an existing Pams field whenever it already captures the information correctly. Pams includes established fields such as **Client**, **Principal**, **Project**, **Currency**, **Delivery Date**, **Payment Method**, **Commission (%)**, **Market Segment**, and **Delivery Term**. Creating another field for information that already exists can lead to conflicting entries and unreliable reports.

A custom-field request is ready to configure when the requester can clearly state:

- What information users must enter.
- Which supported Pams form needs the information.
- Whether a default value is appropriate.
- Where the field should appear in relation to other fields.
- Whether the information needs additional validation or mandatory-entry rules.

[SCREENSHOT: The Configuration area with the Custom fields option highlighted.]

## Step-by-Step Process
1. Open **Configuration** in Pams and select **Custom fields**. Review the existing entries before creating anything new. Check whether another field already has the same purpose, a similar **Name**, or a suitable **Description**. This prevents duplicate fields that users may interpret differently.

2. Start a new custom-field entry. Use a short, business-focused **Name** that users will understand on the form where it appears. Avoid abbreviations that only one department uses. If the same term has a specific meaning in your organization, make the meaning clear in **Description** so future administrators and reviewers understand why the field exists.

3. Choose the supported Pams form where the field is needed. Select only the form that matches the agreed workflow. For example, if the information is collected while a team prepares or follows up a Sales Job, place it on the relevant sales form rather than on an unrelated Product or Project form. Do not assume that a field created for one form will appear on every other Pams screen.

4. Complete the options shown in the custom-field entry. Use **Default** only when most users should begin with the same value. A default should reduce repeated entry, not encourage users to accept an incorrect value without checking it. If **Display Order** is available, place the field near the related information so users can find it naturally while completing the form.

5. Review **Active** before saving. An active field is intended for current use. If you are updating a field that should no longer be used, do not remove information that may already be needed in existing Sales Jobs, Projects, Products, or other Pams forms. Review the impact with the relevant business owner first.

6. Click **Save** to keep working in the configuration entry, or click **Save and Close** when all details are complete.

7. Open the supported Pams form where the field was added and verify that users can see it in the expected location. Enter a suitable test value only where your team’s working practice allows it, then confirm that the value remains visible after saving. If the field is intended to guide data completion, continue with [Configuring Dynamic Validation](doc:configuring-dynamic-validation).

[SCREENSHOT: A Custom fields entry showing Name, Description, Display Order, Default, Active, and Save and Close.]

## Roles and Responsibilities
Use clear ownership for every custom field. Custom fields affect the information users enter during Sales Jobs, Projects, Products, Accounts, Principal work, purchasing activity, and other supported Pams workflows. The person who creates the field should not have to decide its business meaning alone.

| Workflow step | Responsible person or team | Responsibility |
|---|---|---|
| Identify the information gap | Business owner or team representative | Explain what information is missing, why it is needed, and on which Pams form users should enter it. |
| Review existing information | Pams administrator and business owner | Check whether Pams already contains a suitable field, including fields in Configuration and the relevant business form. |
| Create or update the custom field | Pams administrator | Open **Configuration > Custom fields**, enter the agreed **Name** and **Description**, set the available options, and select **Save** or **Save and Close**. |
| Confirm placement and wording | Team representative who uses the form | Verify that the field appears on the intended form, is understandable, and is positioned appropriately using **Display Order** where available. |
| Confirm daily-use rules | Business owner | Decide whether users need further completion rules, such as mandatory-entry or condition-based validation. |
| Maintain the field over time | Pams administrator with business owner approval | Update unclear labels, review defaults, manage **Active** status, and avoid changes that disrupt existing Pams information. |

For Sales Jobs, the business owner may be a Sales Team representative or Salesperson Responsible. For purchasing-related forms, the reviewer may be a Purchaser. For Projects, a PM Responsible or project team representative should confirm that the field supports the actual project workflow. Finance-related requests should be reviewed by the team responsible for Invoices or Payments.

The Pams administrator should keep the configuration consistent, but the business team remains responsible for deciding whether the field is useful, clear, and appropriate for everyday work.

## What Can Go Wrong
Custom fields are simple to add, but unclear decisions can create confusion across daily Pams work. Review the following issues before asking users to rely on a new field.

| Issue | What users may experience | How to fix it |
|---|---|---|
| The field duplicates an existing Pams field | Users enter the same information in two places, such as a custom field and an existing **Client**, **Principal**, **Project**, or **Market Segment** field. | Return to **Custom fields** and review whether the new entry is necessary. Use the existing Pams field whenever it already meets the need. |
| The **Name** is unclear | Different users enter different kinds of information because they interpret the label differently. | Update the **Name** to use the business term your team already uses. Add a practical explanation in **Description**. |
| The field appears on the wrong form | Users cannot find the field while working on the Sales Job, Product, Project, or other form where they actually need it. | Review the selected supported form in the custom-field entry, correct it, save the change, and verify again on the intended Pams screen. |
| An unsuitable **Default** is used | Users keep an incorrect starting value instead of checking the field for each job or transaction. | Remove or revise the default. Keep defaults only for values that are appropriate in most cases. |
| The field is difficult to find | Users overlook the field because it is separated from related information. | Adjust **Display Order** where available, then reopen the relevant form to confirm the new placement. |
| Users need the field under specific conditions | A general custom field exists, but the team needs a rule for when a value must be entered. | Define the field first, then use [Configuring Dynamic Validation](doc:configuring-dynamic-validation) to set the appropriate completion rule. |

After every change, open the relevant Pams form and confirm the field’s label, placement, current status, and saved value before telling the wider team to use it.

## Tips & Best Practices
- Use a field only for one clearly defined business purpose. A field labelled with several unrelated ideas is difficult to complete consistently and difficult to use later when reviewing Sales Jobs, Projects, Products, or Accounts.

- Choose terms that match the language already used by your team and by Pams. For example, use established terms such as **Principal**, **Sub-supplier**, **Client**, **Project**, **Sales Job**, **BOM**, **MRQ**, **RFQ**, or **Delivery Term** where they describe the information accurately.

- Keep **Name** short enough to scan quickly on a busy form. Use **Description** to explain details that do not fit in the label, including when the field should be completed and what the value means.

- Set **Display Order** so the field sits beside related information. A custom field about delivery belongs near delivery-related details, while a commercial field should sit with commercial details such as **Currency**, **Commission (%)**, **Margin**, or **Payment Method**, where available.

- Treat **Default** carefully. A default helps when the same entry is correct for most work, but it can create inaccurate information when users accept it without review. Do not use a default merely to make a form look complete.

- Review custom fields before adding similar fields for each team. A single, well-defined field can support consistent work across Sales Teams, Purchasing, Project management, and Finance when it is placed on the correct supported form.

- Test the field using the normal workflow. If it is intended for a Sales Job, verify it while reviewing a Sales Job. If it is for a Product or Project, verify it from **Products** or **Projects Management** rather than relying only on the Custom fields entry.

- Keep decisions about required information separate from field creation. Create the useful field first, then configure condition-based completion behavior through [Configuring Dynamic Validation](doc:configuring-dynamic-validation).

[SCREENSHOT: A supported Pams form showing a custom field positioned beside related business information.]

## Related Workflows
Custom fields are most useful when they support a defined business workflow rather than collect information without a clear use. Review the related guides below when deciding where a new field belongs and who should own its content.

- [Managing Sales Jobs](doc:managing-sales-jobs) explains the Sales Job workflow, helping sales teams decide whether a new field is genuinely needed during inquiry, offer, order, or follow-up work.

- [Creating Sales Inquiries](doc:creating-sales-inquiries) and [Preparing Customer Offers](doc:preparing-customer-offers) help you identify information that sales users need while qualifying an Inquiry and preparing an Offer.

- [Managing Principal Relationships](doc:managing-principal-relationships) and [Tracking Principal Sales Results](doc:tracking-principal-sales-results) are relevant when a requested field relates to a Principal, represented product portfolio, commission arrangement, or deal result.

- [Managing Product Records](doc:managing-product-records), [Configuring Product Categories](doc:configuring-product-categories), and [Configuring Product Supplier Types](doc:configuring-product-supplier-types) help determine whether product information should be maintained through an existing Product field or needs a carefully defined custom field.

- [Managing Project Workflows](doc:managing-project-workflows), [Managing Bills of Material](doc:managing-bills-of-material), and [Managing Material Requisitions](doc:managing-material-requisitions) provide context for fields requested by project and purchasing teams.

- [Managing Company Accounts](doc:managing-company-accounts) and [Managing Contact Relationships](doc:managing-contact-relationships) are useful when the requested information concerns Accounts, Clients, Contacts, Principals, or Sub-suppliers.

- [Managing Default Layouts](doc:managing-default-layouts) helps when your main concern is how users view established information on Pams forms rather than collecting a new value.

After creating the field, use [Configuring Dynamic Validation](doc:configuring-dynamic-validation) to define when users must complete it.

## FAQ
### When should I create a custom field instead of using an existing Pams field?

Create a custom field only when the information has a clear business purpose and no existing Pams field captures it correctly. First review the relevant form and familiar Pams fields such as **Client**, **Principal**, **Project**, **Currency**, **Delivery Date**, **Commission (%)**, **Market Segment**, and **Payment Method**. If one of these already answers the business need, use it rather than creating a duplicate.

### Can I update a custom field after it has been saved?

Yes. Open **Configuration > Custom fields**, locate the field, and update the available details such as **Name**, **Description**, **Display Order**, **Default**, or **Active**. Click **Save** or **Save and Close**, then open the supported Pams form to verify the result. Review changes with the business owner first, especially if users have already entered values in existing Sales Jobs, Projects, Products, or Accounts.

### Why can users not find the new field?

First confirm that the field was created for the intended supported Pams form. Then review **Active** and **Display Order** in the Custom fields entry. Reopen the relevant form after saving to verify where the field appears. If it still does not appear where expected, do not create another duplicate field; review the existing configuration and the selected form.

### Should every custom field have a default value?

No. Use **Default** only when the same starting value is correct in most cases and users can still review it before saving. A default that is often wrong can reduce data quality because users may leave it unchanged.

### Can I make a custom field mandatory?

Create and verify the field first. If your team needs the field only in certain situations, such as for a particular Sales Job, Offer, Project, or commercial condition, use [Configuring Dynamic Validation](doc:configuring-dynamic-validation) to set the completion rule.