Data Type vs Field Group

[navink386520]

While I can create reusable attribute grouping via Field Group, i always confused as to when and why i should use grouping of attributes as Data Type vs Field Group.

I understand FG is root node, while DT is not root node. However , is that the only difference, or any use-cases around when and why?

[ChetanyaJain · Accepted solution]

Hi @navink386520 

This is my way to visualize the DT & FG:

Data Type	Field Group
Data type is a set of fields	Field group is a set of data types & fields
Data type can contain another data type	Field group cannot contain another field group
Data type can be added to the schema at any position. It can also be added at multiple places as well.	Field group always remains at the root level and they can be added only once.
You can create an array for the data type to capture multiple entities as well.	Field group, you add at the schema level
Data type can be associated with any class	Field group is associated with a specific type of class

See if this helps or if you have any follow-up questions.

Thanks,

Chetanya Jain

[navink386520]

Good one bud

[Gokul_Agiwal]

Hi @navink386520 

In very simple terms 

Field -> Defines a single small file which has a data of specific type. For Ex: Currency code as Field which contains data as String. 

Data Type -> Collection of Fields aligned to a specific business patterns. 

Field Group -> Collection of data types and fields for a specific use case and this is then used to extend the Schema.

[adobechat]

field group is a collection of fields. Data type is the definition of the field itself, hope this is clear.

[Anil_Umachigi]

@navink386520  In addition to all the other comments, let's understand this with some usecases/example. 

Usecase1 Understand search behaviour, trends and keywords on the website, specifically our a.) Product search b.) store search c.) faq search. 

Now if you take a step back and review the requirements, the kind of data required for each of these are similar ( kw, location, # of results etc..) while some data requirement may be specific to each search application. 

In this instance we could figure out if there is a data type (either out of box) already available for us to use or we create a new data type which can be then re usable. 

In our use case ( Internal search data type) fits the bill, and we could use the same data type in three custom field group. In addition each field group can then consist of additional fields specific to each search type for additional customisation. 

So your schema will look like so.  

_tenantID

      productSearch : {}

      faqSearch: {}

      storeSearch: {}

P.S: Advanced usage would be using a single field group to capture all search types, assuming all search app works the same. 

Usecase2: Digital Marketing team wants to track "internal campaigns", while the customer support (chat) wants to track their own interaction driven campaigns.  

Solution: In this use case the core data required ( cmp name, cmp code etc.) is similar with few additional data points specific to campaign source and type. 

We could use Marketing data type to achieve this, create multiple field group and add additional fields specific to requirement.  

Hope that helps. 

Anil

[Luca_Lattarini]

@Anil_Umachigi Is it correct to say that if we want to make  a service re-usable and consistent  at level record and time-series. The best choice is to create a Data Type  ?