The custom field ideology

From Planfix
Revision as of 10:54, 16 December 2023 by Aliona (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Let's take a look at the ideology behind custom fields. We'll use adding a "Customer request" entity to the system as an example. According to the Planfix's philosophy, a customer request is a task that has additional properties. In order to use the full potential of Planfix task tools for working with requests, we set up a separate template for them:

  • Create a new Object called "Customer request"
  • Add the necessary fields to it, describing the request (type and dimensions of the product, type of requested service, delivery address, etc., depending on the company' specializations).
  • Hide fields that are not needed for working with requests
  • Save the resulting Object and get the opportunity to work in Planfix with tasks of a new type
  • Whenever creating tasks with this template, employees will have the opportunity to fill in the necessary fields of the request.
  • It is convenient to filter tasks by the field, specific only for requests - so ordinary tasks, created based on the standard template, will not interfere with request-tasks.

This approach allows you to work simultaneously in one Planfix account with different business processes, using the common system tools and dividing tasks into separate branches.

Cross-object usage

You can use this custom field in all relevant Planfix. For example, the custom field "vehicle number plate" can be used in the "Customer request" object, and in the "Purchase" object, and in the "Technical work" object. This will allow, if necessary, to keep track of cross-object statistics - for example, to display in reports the total use of transport with grouping by types of use, projects, etc.

Go To