The custom field ideology: Difference between revisions

From Planfix
Jump to: navigation, search
No edit summary
No edit summary
Line 1: Line 1:
Let's take a look at the ideology behind custom fields. We'll use adding a "Customer order" entity to the system as an example. According to the [https://planfix.com/philosophy/ Planfix's philosophy], a customer order is a task that has additional properties. In order to get the most out of the Planfix task toolkit, we set up a separate template for orders:
{{#seo:
|title=Ideology of using custom fields
|titlemode=append
|keywords=planfix, custom fields, ideology, field
|description=Ideology of using custom fields
}}


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 [https://planfix.ru/ideologiya/ 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 [[Task templates | task template]] with the name "Customer order"
*[[Creating custom fields | Add the fields]] that are characteristic of an order (the type of product or service ordered, product size, delivery address, etc. — these will depend on your company).
*[[Creating and configuring a custom field in a task template | Hide fields]] that you don't need when working with orders.
*When a task is created using this template, employees will be able to fill in the task fields with order data.
*Down the line, order tasks can be selected using [[Task filters | filters]], displayed in [[reports]], and displayed in [[Planner]] lists.
*Selecting by a field that's specific to orders comes in handy when you need to be sure that you're selecting only tasks for orders.
   
   
*Create a new [[Objects|Object]] called "Customer request"


This approach gives you the ability to use one Planfix account for what are essentially multiple business processes, simply by dividing tasks into separate sections and using the tools built into the system.
*Add the necessary [[Creating custom fields|fields]] to it, describing the request (type and dimensions of the product, type of requested service, delivery address, etc., depending on the company' specializations).


*[[Object form|Hide fields]] that are not needed for working with requests
==Comprehensive use==
 
Custom fields that are created can be put to use in any Planfix task where they are relevant. For example, the custom field "Vehicle number" can be used in "Client order" tasks, "Purchase" tasks, and "Technical operations" tasks. This lets you gather comprehensive statistics on the field as needed. For example, you can display the total usage of transport in a report, grouping by type of use, project, etc.
*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.
 
*Furthermore, request-tasks can be selected using [[Task filters|filters]], displayed in [[Reports|reports]] and [[Planner|Planner]] lists.
 
*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==
== Go To==
*[[Custom task fields]]
*[[Custom task fields]]

Revision as of 10:05, 16 December 2023

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