The next auditing technique that we have going to talk about is a field audit trap in the previous session.
We understood about field history tracking right.
So what is basically field history tracking it is under that auditing technique where we track the changes
that are taking place in the field and then we capture those information and we pull those the information
and the reports.
So in the previous video we had a very into end understanding about that.
What does field history tracking how to configure that.
What all the I'd want is just how to extract those data how to use that in reports.
So all those information we already discussed in the previous session.
Now the next technique that we are going to talk about is field audit track this field audit trail.
And the field history tracking basically the underlying concept is the same in both these techniques.
We track the changes that are taking place in fields in standard objects and custom objects.
So the underlying concept is the same but just that field audit trail is a much bigger version of field
history tracking so in field audit trail it is basically a policy to retain the archive of field history
data for up to 10 years from the time the data was archived and we see that the time duration is much
bigger than what we have for field history tracking and this is a quick comparison all for the board
the Auditing Techniques the field history tracking and field audit trail field history tracking the
data is retained for up to 18 months or 24 months where the API but in theory audit trail the data is
retained for up to 10 years I feel history tracking we can track up to to any fields or object in field
audit trail we can track up to 60 fields per object and field history tracking it is very much a we
are very much able to configure that using Salesforce you why.
All right we understood how to do that.
Another development addition enabling field straight tracking choosing the fields and pulling the related
list to the layouts and pulling the data in the form of reports.
So all the configuration we were able to do it in sets policy why but in field all the trail we'll be
using Salesforce metadata API for defining retention policies and this field history tracking it comes
at no additional cost our full license we can use that for setting up this technique from end to end
but for field audit trail it is basically a paid ad on product and that paid ad on Product Disclosure
less sales skills sheet.
So that comes at a cost.
You just are not free like field history tracking ones we chase that ad on product sense.
She then will be able to use the auditing technique field AUDIT CHAIR IN OUR cesspools.
Arg and the other main difference is that field history tracking it is available in development additions
so that does why we were able to understand how it works but field audit trail.
It is very much understandable right to spade so it does not available in developer edition and as is
is not available in the developer edition will not be able to exactly see how this functionality is
configured and how we'll be able to use that and Salesforce.
However for our learning purpose I'm going to share as much information as possible to help us understand
this concept of field trip
field audit trail.
We know it lets us define a policy to retain the archived field history data for up to 10 years from
the time it was archived.
All right so that is the concept of field audit track and this feature will help us comply with the
industrial regulations related to audit capabilities and other data retention.
So basically that is the whole concept of auditing and this feed on the trailers are definitely a very
effective tool in helping us with other auditing capabilities and our data retention policies.
And similar to field history tracking we can enable this functionality for both the standard objects
and custom objects as a standard objects.
Almost all of the standard objects like accounts contacts cases leads opportunities orders.
Most of the client standard objects and custom objects asked what this is similar to field history tracking.
And here in this field audit trail there are some restrictions and the following fields here they can't
be tracked.
The fields are formula fields it all up summary fields are the number fields created by last modified
by and expected revenue fields and opportunities.
The long text fields month is select fields of all these fields can be tracked using field audit track
and we need to make a note of this exception.
Perfect.
So now we know what is field auditor and what role the data types or fields that can't be tracked using
field auditor.
Now let's take a quick look about the sales force shield ad on product and how to use this.
A field audit track.
So since we'll see a shield as we mentioned earlier it is basically a paid product.
And when we after we purchase the paid product will have access to field audit trail only then we will
be able to access a field audit trail and configure.
That's another application.
And as usual sales representatives are the best people to reach out to.
If you want to enable field auditor for your organization so does a sales machine.
It is basically a combination of a three security tools and vetted all the three security tools platform
encryption even to monitoring and field audit track.
So this a sales force shield the product the paid product.
It is a combination of these three security tools that the salesforce administrators and Salesforce
developers we can use for a building up the new level of compliance and governance into the business
critical applications.
Let me quickly show you some information from the Census website regarding this product so here is some
information from the sales bulls website regarding the sales force shield product.
And as I mentioned earlier it is a combination of a three tools the platform and corruption even monitoring
Mansfield audit track.
This field audit trail is what we are talking about in this session.
And this field audit trail.
It helps us to understand the state and value of our data.
For any date anytime and this data that we collect is very much useful former auditing purpose on pennies
to create a forensic data level audit trail that up to 10 years of history and we can also set triggers
for when the data is deleted perfect.
So I know that we have a good high level understanding of our field audit trail.
The concept let's get into some of the details about what what happens basically while configuring this
functionality in Salesforce
so eventually a company decides to purchase this paid product.
The first point of contact would be the sales force representatives.
So we need to contact that Salesforce customer support and we need to purchase this product samples
sheet.
This is a paid product.
And once we purchase this product we get access to this feature field Artist Track.
So basically what happens is behind the scenes if we can recollect some concepts from field history
tracking.
So what happened and feels a history tracking what happened during the configuration the enabled field
history tracking functionality for the objects that we would like to track.
So once we enable that functionality for an object then we need to set up those fields which we would
like to track for that particular object.
And we know that up to 20 fields can be tracked and feel history tracking.
And once we do this configuration setup then we need to pull in the related list the history related
list into the layout and that is that is where we'll be able to see all the changes that are happening
in the field.
All right.
So that is a bold field history tracking and that does how we configured design and we were able to
read the information here in field audit trail.
What happens is the field history is basically copied from the history related list into field history
archive big object.
And yes it is a big object considering the huge volume of data that will be loaded into this object
from various fields across various objects.
So the field history data is basically copied from our history related list to this field history archive.
Big object and what data is basically copied into the object that is defined in our history retention
policies for the related history list.
Like I say for example account history to specify field audit trail retention policies for the objects
we want to archive.
And then finally we use Salesforce metadata API to deploy the big object after we define and deploy
the field auditor and policy the production data that is migrated from the related history list such
as account history into this field history archive big object.
And it is very much understandable the first time it does the first copy it drives the field history
that is defined by the policy into this archive storage right and and it takes time.
Because that would be huge volume of data but then the subsequent copies the transfer would be comparatively
less time depending because it will only copy the data from the last time it was transferred.
So the first time it takes a lot of time to copy the information into this big object but then after
that the subsequent copies will take much less time.
Now let's talk a little more about this about this history retention policies.
I would also like to show you the Salesforce implementation guide for the field audit track.
This basically gives in a lot of information about this concept.
So then they say these retention policies basically like how does a field audit trail a difference from
the field history tracking the number of issues that are being tracked right and the huge volume of
data that is being archived and that is therefore a reference.
So that is the whole concept so loved this.
So this also field audit trail when we define the retention policies.
There are a couple of things that we need to define.
First one is archive after months.
So basically this specifies the number of months that we want to maintain this field history and Salesforce
and archive retention years the number of iOS that we want to retain this field history in the archive.
So these are some of the parameters that we need to mention and for which are all objects that we would
need to mention for which are all objects that are being tracked by the field history tracking for those
objects.
We need to mention this.
We need to set these attributes.
So basically there's a field audit trail.
It captures information of all the objects and the fields that are enabled for field history tracking
for capturing the information.
And on top of it for each of the object that is being tracked the this field audit trail we need to
set these parameters for how many months the data should return and Salesforce and for how many years
that we want the data to retain in the archive.
So all these parameters need to be defined.
And as I mentioned earlier we'll be using Salesforce metadata API for setting up all this retention
policies.
So this is basically a sampler piece of code for us to get an understanding of how to define the retention
policy for a particular customer object.
If you see there is a particular custom object and we are defining the sheet history retention policy
for that and we are setting up the archive after months will be six.
So six months the data that will be maintained and Salesforce and archive retention years is five.
So meaning that for five years that we would like to retain the full history in the archive and like
every other component we have a description so that we can use it for future reference like why we basically
set it up like this and why we need that data for that period of time and this a piece of gold it gives
us a just a quick understanding of for how Hollywood is actually done in real time.
And this one this is the package our someone flight landed list up various objects for which data retention
policy has to be applied and we see that a cases context leads and opportunities.
And then finally we'll be using the deploy function to deploy the changes to the production environment
and this one is a sample piece of code for how to create a custom object and also how to set the field
history retention policy at the same time and yes we cannot build the retention policies for field history.
How many other times we want.
So a basically a V is headed for some certain field and for certain objects and we are free to update
those retention policies as and then like the requirement changes.
So yes we can do that as well and we can also retrieve those archived data by making ISO Q and credits
we can use it to be basically available for us to query the object to name as a field history archive
we can use that stock credits the different fields that are available in this particular table as these
so we can use these queries and we can pull the information but affect us so what we understand from
this is that field audit trail is a much bigger wash in off this field history tracking right bead the
number of fields and be the number we use that data is tracked it is a much bigger version of this field
history tracking and the other main difference that we see is that they didn't was core competence right.
Once we purchase the product and the ones we enable this field already trailing over are the like how
do we pull the data.
How do we deploy that the big object like core competence are involved
and we see that to Salesforce metadata API using notable for using this functionality so if you would
like to basically walk around this coding part of it there are a couple other options that are available
to us an app exchange you definitely like we have many of what Salesforce awesome apps that we can use.
So one such.
Let's let's quickly talk about a couple of such apps that we can use for food on the trail.
Go for app exchange.
Let me show you one of the products.
But again this is again a paid product that helps us to work with this auditing technique with ease.
The field audit trail cockpit basic.
So I think this is basically a basic question of that so they may have some or wants to wash itself
this leg check that out.
So this basically what does is once we purchase the sales force shield a product from sales force instead
of quitting instead of basically using the metadata API for setting up the field retention policies
that they have a click can code concept.
So basically they have configured all that and they are giving it to us in a much easier version of
it.
So.
So we have we have to just click and configure that just how we use other declarative features.
So.
Let me quickly show that to you okay.
Given your Stansfield credentials to install this app into your developer liquidation while installing
you can specify whether it is for admins or whether it is for some specific profiles and this being
a tool which is very specific for admins and developers like me will you choose admins here and install
installation complete.
Done.
We see that that particular app is under installed packages.
Okay.
Let's go ahead and access that app.
You should be able to see that under one of the apps.
So let's go for field already child cockpit
and this is where you see the overall information about the fields and the objects that are being tracked
so all the objects that are checked they are being tracked and for each of the object there.
This field history tracking this enable we have the number of fields that are being tracked so for case
object ten fields are being tracked and here you see the number of months that the data should be in
the sales force and the number of is that that data should be retained in the archive.
So while for modifying this you just need to say 80 years for a fact and then we say update policies
just click of a button.
That's it.
So what.
No I think you can compare how this is a much easier way to walk around the rather than the metadata
EPA but yes it comes with a cost.
All right.
It's not free.
So when you say update policies.
Yeah.
I'd say that field auditor does not seem to be enabling in this organization yet it is not enabled.
Right.
We did not chase the salesforce shield paid product.
So once we put chase that we can use this app to basically work around the coding metadata API part
of it to set up all the retention policies we can set up the months the years the description and all
these and just click of a button that's it but again this is a paid product.
So it is completely up to your company to decide whether you need to go with this paid product or use
Salesforce metadata API for working on your retention policies and for deploying the competence.
So this is one of the app exchange app that we have for enabling this working with this field audit
trail thing and the other app exchange app that I would like to show you.
This is the other app that I would like to show you.
And it says it started up close to 500 dollars per company per month.
This is again a similar app offering like that easy archival and a single click restore process data
archival supports field audit trail system audit trail and any level of object relationship archiving
basically on other similar app offering these auditing services.
And again this is a paid app and it is up to a company to decide whether to go with this paid app exchange
app artistic onto this as well as metadata API.
So this is all about the field audit trail.
No I was not able to show exactly how to configure and work that in our developer edition.
Apologies for that because it is not available in developer edition.
I'm just like trying and giving you as much as information possible for us to know regarding this concept
because as a senior airman when we talk about data auditing when we talk about the various options that
are available out to you as a senior I mean it is your responsibility to give old weighed his options
to the management saying that since those officers have those office that since those officers.
So they need to give all the various options that are available for data auditing so that as a team
we can decide on which is the best auditing technique for us.
So having information regarding a particular topic is very essential.
As a senior admin.