CUSTOM REPORT TYPES NEEDS AND FEATURES

INTRODUCTION 

A report is a list of records that meet your defined requirements. It can be sorted, clustered, or shown in a graphical map in Salesforce and is shown in rows and columns. 

Each report is kept in its own folder. Folders can be made public, secret, or exchanged, and read-only or read/write and permissions can be set. Based on roles, permissions, public groups, and license types, you can control who has access to the contents of the folder. You may render a folder public or private so that only the owner has access to it. 

Every report is built around a specific report type. Only records that meet the requirements specified in the report type are shown in reports. One of the most crucial steps in creating a report is deciding on the appropriate report type. You choose the records and fields that will appear in your report when you choose a report type. Let's see what Report Type has to offer...… 

WHAT IS REPORT TYPE ?

A report type is similar to a prototype that simplifies reporting. When making a report, the report type decides which fields and records are accessible. The relationships between a primary object and its associated objects are the basis for this. 

The report type dictates the records are included in the report. When creating a report, the report type is chosen first. A primary object and one or more related objects exist for each report type. All of these items must be linked, either directly or indirectly. 

In Salesforce, there are two forms of report types:- 

1. Standard Report Types
   

   Standard Report Types are included by default for standard objects and custom objects that have the “Allow Reports” checkbox selected. Standard Report Types are not customizable and contain standard and custom fields for each object within the report type by default. When an object and/or a relationship are created, standard report forms are created as well. 

   As an example, the primary object in the 'Contacts & Accounts' report type is 'Contacts,' and the associated object is 'Accounts.' 
   
   

   
   

2. Custom Report Types
   

   Custom report types are reporting models that have been designed to make the reporting process more effective. An administrator or a user with the permission to "Manage Custom Report Types" may build Custom Reports. 

   We may define items that will be available in a specific report in custom report types. Custom Report Types can endorse the following object relationships: 

• Each "A" record must have at least one related "B" record. 
• "A" records may or may not have related "B" records. 
  
  

The following are described by Report Types: 

• Objects: Which Objects Can Be Seen by the Report 
• Object Relationship 
• Field layout 
• Default Field 
• Field name 

• 
  

WHY WE NEED CUSTOM REPORT TYPE 

The first step in creating a report in Salesforce is to choose a report type. Salesforce has a lot of pre-defined Report Types, which is awesome, but they don't always have exactly what we need. Standard report types cannot often have visibility through all the records or fields we need, or standard report types may be too difficult to use effectively.

You can't change Salesforce's predefined Report Types because they must be consistent with all orgs. Salesforce, fortunately, allows you to build custom report types. When standard report types can't determine which records will be available on reports, custom report types are developed. 

FEATURES OF CUSTOM REPORT TYPES 

Custom Report Types make creating nuanced, interactive reports that go beyond traditional Salesforce reports a breeze. We'll need to create custom report styles if we want to create reports that aren't normal. In comparison to regular report types, custom report types provide a number of advantages. Let's look at the features of custom report types in more detail... 
 

1. Rename the field section folder name 

The field panel in Salesforce's report builder does a good job of grouping fields, but some fields belong in a separate folder area. It's possible that a completely new custom folder section would be needed. 

We can change the folder name that grouped all the fields while creating a report.

 

2. Lookup Fields are a great way to add more fields 

You can not only add or delete fields related to the objects in the report type, but you can also add additional fields from related objects to the report. 

Under the object pick list, you'll see a connection that says Add fields related through lookup. When you click this, all of the objects that are connected to the selected object will appear. 

Now using this feature, we can get value from the related objects. 

 

Set Default Fields 

Salesforce will fill the report with a few default fields when you choose a regular report form. This makes the task of creating reports a lot simpler. 

Users must take some extra precautions when using custom report types since no data has defaulted. However, you can give the report some immediate value by defaulting fields to the report form, giving users a report prototype to work with right away. 

This allows the user to create a default layout by creating default fields. 

 

3. Reports with specific fields hidden 

We may also specify which fields can be recorded using custom report types. 

Have any old fields you don't want users to be able to access in a report? Perhaps you just want to reduce the number of fields you can report on in order to speed up the report development process. It's possible! 

Although fields may be omitted, it's worth noting that fields can need to be added to the report form at times. When you add new fields to an item, they don't always appear in the report because they haven't been added to the report type. 

 

WE'LL LEARN HOW TO CREATE CUSTOM REPORT TYPES AND SET FIELD LAYOUT FOR REPORTS IN OUR NEXT BLOG. 

If you have any questions you can reach out our Salesforce Consulting team here.

Lifecycle Hooks - Lightning Web Component

INTRODUCTION

A lifecycle hook is a JavaScript callback method which is called at a certain point in the lifecycle of a component instance. The components' lifetime was managed using the Aura system's init(), render(), rerender(), afterRender() and unrender() methods. In Lightning Web Component, callback methods are used to manage the components' lifespan, Lifecycle hooks are what they're called. You can adjust the actions by overriding these hooks. There are various life cycle hook methods to pick from, and we will go through each one in detail in this blog.

Here are the Types of lifecycle hooks

1. Constructor():

• Whenever a component instance is created, this hook is invoked. 
• The first statement must be super() with no parameters. 
• Don’t use a return statement inside the constructor body.
• This hook flows from parent to child, which means that it fires in the parent first. You can't access child elements because they don't exist yet. Properties aren't passed yet, either.
• Properties are assigned to the component after construction and before the connectedCallback() hook.
• The similarity of this hook in Aura is with init() event but init() Aura event flows from child to parent.

sample code

2. connectedCallback():

• it fires when a component is inserted into the DOM. 
• The connectedCallback() hook can be fired more than one time.
• This hook flows from parent to child. You can’t access child elements because they don’t exist yet. 
• Use connectedcallback() to interact with a component's environment. For example, you can utilize it for:
• Establishing communication with the current document or container and coordinate behavior with the environment. 
• Performing initialization tasks, such as fetch data, set up caches, or listen for events.
• Subscribe and Unsubscribe from a Message Channel.

SAMPLE CODE

3. disconnectedCallback():

• Invoked when the element is removed from a DOM. 
• This hook flows from parent to child.
• Use disconnectedCallback() to clean up work done in the connectedCallback(), like purging caches or removing event listeners.
• You can also use this hook to unsubscribe from a message channel.

SAMPLE CODE

4. render():

• To update UI, we can call this method. It may be called before or after connectedCallback().
• It is rare for a portion to be referred to as render(). The most typical use is to apply correct template (HTML file) based on business logic. The method must return correct HTML template. 
• For example, imagine that you have a component that needs to be rendered in two different ways but you don’t want to mix it in one HTML file. So, here we can create multiple HTML files in the component bundle. And then Import  them and add a condition in the render() method to return the correct template depending on the component's state.

SAMPLE CODE

FirstTemplate.HTML

SecondTemplate.HTML

App.HTML & App.js

5. renderedCallback():

• it is called after rendering of every component. This lifecycle hook is specific to Lightning Web Components, it is not from the HTML custom elements specification. This hook flows from child to parent.
• A component is rerendered when the value of property changes and that property is used either directly in a component template or indirectly in the getter of a property that is used in a template.
• As this hook is called after every render of the component, we need to be careful if we perform some action in specific condition. It should be guarded with the condition that doesn't trigger an infinite rendering loop.

SAMPLE CODE

6. errorCallback(error,stack):

• It captures the errors that may occur in the lifecycle hooks of all descendant components.
• The error argument is a JavaScript native error object and stack parameter is a string.

SAMPLE CODE

summary

The framework manages the lifespan of Lightning web components. When the state of a component changes, the framework generates components, adds and removes them from the DOM, and renders DOM modifications. 

If you have any questions you can reach out our Salesforce Consulting team here.