Custom fields in DFP sales management
|This article is for DFP administrators or roles with similar permissions|
This article describes the behavior of custom fields under DFP sales management and some additional configuration that sales management networks enjoy. We'll cover:
Custom fields are additional fields you can add to DFP "objects"—like orders, line items, proposals, and products. They do not affect ad serving or delivery but simply provide additional information and can be used in reporting.
They are created by a DFP administrator and applied to the objects where they need to appear. For example, there might be a custom field called "Internal Invoice Number" that applies to orders. When an order is created, you can select this field and add your organization's internal invoice number.
In DFP sales management, the objects that can have custom fields include product templates, products, proposals, or proposal line items. Many of these objects are closely related and used as the source to create a "downstream" object.
For example, DFP administrators create product templates, and these product templates generate products. The product is connected to the product template as a downstream object. Under certain circumstances, if the product template is updated, the product is also be updated.
Similarly, sales representatives select products from the catalog to add to proposals. These products are copied to the proposal and become a proposal line item. When the proposal is sold and finalized, DFP creates a corresponding line item under the "Delivery" tab for each original proposal line item in the proposal. The line items DFP creates that correspond to the proposal line item are also downstream objects. If updates are made to the proposal line item, those updates can be pushed to the line item.
Custom fields may not always display in every downstream objects, depending on which object the custom field appears. Here is a summary of sales management objects that can have custom fields and a note about whether custom fields carry over to downstream objects:
- Product template: field appears in product templates, products generated by that template, and in any proposal line items that are based on the product as read-only information.
- Product: custom field appears in products and in any proposal line items that are based on the product as read-only information.
- Proposal: custom field appears in proposals and carries over to orders as read-only information.
- Proposal line item: custom field appears in proposal line items and in corresponding line items as read-only information.
: is a product template with custom fields : is a product in the catalog with custom fields : is a proposal line item created based on that product which also has custom fields : is a corresponding line item for the proposal line item : an editable custom field created for that object : a read-only, inherited custom field from an upstream object
Importantly, each object has its own, distinct set of custom fields. The custom field that you create for a product and carries over from the product to a proposal line item is not the same custom field that you create for a proposal line item and carries over to a corresponding line item.
A custom field that is created and editable for an object carries over to a downstream object and becomes read-only in the downstream object. For example, if sales representatives need to provide additional instructions to traffickers in delivery line items, you would create a custom field for proposal line items, whereby they can indicate those instructions. The field would then display in line items as read-only information.
Note that product templates are the only object whose custom fields carry over to more than one downstream object.
Custom fields is a DFP-wide feature. You can review general instructions on how to create custom fields in Custom fields.
In some of these locations (for example, product templates), you can also specify that a custom field be mandatory. When you set a custom field as mandatory, users editing an object where that field is located need to complete the field before saving successfully. You can find the "Set as mandatory" option just under the "Location" setting when selecting some sales management fields.
Some important best practices to keep in mind when creating mandatory custom fields:
- Mandatory custom fields must be set to "Editable" and not "Hidden" or "Read-only".
- If the custom field type is set to "Drop-down", ensure that you add values for the drop-down menu. A mandatory drop-down menu without values means that the user editing an object will not be able to save successfully as no valid mandatory value can be selected for the drop-down menu.
Text fields that are set to mandatory do not need a value for users to save successfully as null (no value) is considered a value.
Product templates and mandatory custom fields
When you add a custom field to product templates and designate it as mandatory, DFP enforces the new mandatory custom field in future product templates created. This means that, when administrators try to create a new product template, they need complete the mandatory custom field before they can successfully save the new product template.
Existing product templates and are not immediately affected however. DFP won't enforce the new mandatory custom field until the existing product template is edited. This means that the product template (and any downstream objects) won't reflect the new, mandatory custom field until an administrator tries to update the product template.
Once an existing product template is edited, DFP enforces new mandatory custom fields, and administrators won't be able to save unless the mandatory custom field is completed successfully.