Settings Reference
anyei
Custom Metadata Type and Custom Setting
ATARC Process Settings custom metadata type
The custom metadata type ATARC Process Settings is a key player in the overall architecture of ATARC as is the source from where the engine will get what processes will run on what particular object/event. In other words, you need this to define a process to run. One record in this custom metadata type represents a process/apex class to run.
Each field in the custom metadata type is tied to a particular ATARC feature and plays a role (except the "Description" field, it is just to provide a brief description of the process/apex class and the "Label" field).
So the following table gives you an idea of how this custom metadata type records looks with records:
|
Label
|
ATARC Process Setting Name
|
ApexHelperClassName
|
SObject
|
Event
|
IsActive
|
IsAsync
|
Order
|
DependsOnSuccess
|
DependsOnFailure
|
Debug
|
DebugLevel
|
breakIfError
|
Isolate
|
Override Loop Limit
|
LoopLimit
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Name Changer
|
NameChanger1
|
NameChanger
|
Opportunity
|
BeforeInsert
|
true
|
false
|
1
|
true
|
DEBUG
|
false
|
false
|
false
|
1
|
||
|
Win Probability
|
WinProbabilityCalc
|
ProCalculator
|
Opportunity
|
BeforeInsert
|
true
|
false
|
2
|
NameChanger1
|
true
|
DEBUG
|
false
|
false
|
false
|
1
|
|
|
Complex Notification
|
ComplexNotification
|
ComplexNotifyier
|
Opportunity
|
AfterInsert
|
true
|
true
|
1
|
true
|
DEBUG
|
false
|
true
|
false
|
1
|
Fields
Atarc Process Setting Name
The name of the process, this field is unique (regular DeveloperName field on custom metadata types). ATARC use this field to identify the process. Also it is used by other processes to access to particular information, such as the status of the process (executed successfully or failed) or data output produced by a process.
The following is an example shows the usage, the method getProcessData which is part of the triggerContext parameter, use the atarc process name to get the result of the execution of 'NameChanger1' (in this case 'NameChanger1' ran before RocketLauncher process:
public class RocketLauncher extends AsyncTriggerArc.AsyncTriggerArcProcessBase {
protected override object execute(AsyncTriggerArc.AsyncTriggerArcContext triggerContext){
object outputData = triggerContext.getProcessData('NameChanger1');
system.debug('data from NameChanger1 ' + outputData);
return null;
}
}
ApexHelperClassName
Name of the helper class with the functionality (code) that will be executed by ATARC from within the specified trigger. This apex class must exist in the org and it must extend the base class AsyncTriggerArc.AsyncTriggerArcProcessBase or AsyncTriggerArc.AsyncTriggerArcFEAProcessBase.
You can specify an inner class as well as long as they have the public access modifier, for example: MyFirstClass.MySecondCalculator MySecondCalculator would be a public class defined within MyFirstClass.
SObject
The name of the SObject where you have a trigger with the engine instantiated. ATARC use this along with the Event name to determine when to run the apex class specified in ApexHelperClassName field.
Event
A value represents the trigger event the process will run on. The possible options are the following (cannot combine them):
- BeforeInsert
- BeforeUpdate
- BeforeDelete
- AfterInsert
- AfterUpdate
- AfterDelete
- AfterUndelet
isActive
Checkbox/boolean switch to turn on/off. If true ATARC will take the process into consideration to run, otherwise it will not even be evaluated.
General Availability
Checkbox/boolean switch to turn on/off. If true ATARC lets the Atarc Process to execute by any running user, with the exception to those prevented by ATARC Process Availability Rule. If false, ATARC will not let the Atarc Process to execute by any running user with the exeption of those specified by ATARC Process Availability Rules.
isAsync
Checkbox/boolean switch to turn on/off. If true ATARC will run the specified apex class as a queueable using a queuable wrapper. According to the ATARC Best Practices there are little few scenarios where you will run the specified apex class with this set to true from within a before events, so please keep in mind it is very important that all the pieces are in the correct place in order to get the max out of your transactions.
This is a powerful feature which used wisely it could help to reduce a lot of transaction stress from your org. Processes with isAsync set to true may affect the order of execution. The field "Isolate" affects directly the queuable behavior, further in this documentation there is a description specific for this field.
Isolate
Checkbox/Boolean switch to turn on/off. If true and "IsAsync" is also true, the queueable transaction will not be shared with any other process further in the list, that means the queueable will get enqueued so that salesforce runs it whenever it wants, then the next processes to execute will be executed without waiting for it to finish. See the next simple graphic as example:
IsAsync=true Isolate=true
trigger transaction begins>>------enqueue process 1-------execute process 2------execute process 3-----execute process 4-----trigger transaction ends
.
.
queueable transaction begins-----execute process 1-----queueable transaction ends
If false and "IsAsync" is true, the queueable transaction will be shared with any other process further in the list, that means the queueable will get enqueued and then once salesforce runs it, the atarc engine will execute the next pending processes from the queueable transaction. See the next graphic as example:
IsAsync=true Isolate=false
trigger transaction begins>>----execute process 1------enqueue process 2------trigger transaction ends
.
.
queueable transaction beings-----execute process 2------execute process3-------queueable transaction ends
This means chaining async processes is possible (as they are technically using a queueable wrapper) when the Isolate field is set to false and IsAsync true, consider the following graphical example:
IsAsync=true Isolate=false chaining
trigger transaction begins>>----enqueue process 1-------trigger transaction ends
.
.
queueable transaction beings-----execute process 1-----enqueue process 2-----queueable transaction ends
.
.
queueable transaction begins-----execute process 2----enqueue process 3------queueable transaction ends
.
.
queable transaction begins------execute process 3------queable transaction ends
- Keep in mind, as of now, salesforce only permits 5 level of chaining (depth), it will throw an error when you try to enqueue the level 6. Try to avoid chaining more than 4 async processes to keep it safe.
-
Keep in mind also, as of now, salesforce only permits 1 queueable to be enqueued from a queueable execution context. As example, if you were to execute three or more async processes, in which the first one has the isolate configuration not checked, but the rest as isolate configuration checked so that it looks like the following:
trigger transaction begins>>----enqueue process 1-------trigger transaction ends . . queueable transaction beings-----execute process 1---------enqueue process 2------------------------------------------------------------------------enqueue process 3-----------------------queueable transaction ends . . . . queueable transaction begins-----execute process 2------queueable transaction ends . queueable transaction begins-------- execute process 3-------queueable transaction endsThe process 2 will be successfully enqueued so that it is executed with its own isolated execution queueable transaction, however, the process 3 will not be executed with its own queueable transaction, rather process 1 and process 3 will share the queueable transaction.
This is due to the hard limit on salesforce previously described so ATARC engine will not allow this particular scenario and it will do as explained previously.
Order
Numeric field representing the order for the process when multiple process are hooked with the same combination of sObjectName/Event. This gives you real control of what goes first and what's next.
breakIfError
Checkbox/boolean switch to turn on/off. If true, if an apex code exception occurs within the specified apex class ATARC will let that exception to break the execution of the current transaction. If false, ATARC will not let the exception breaks the current transation's execution. Salesforce gorvernor limits cannot be catched therefore any governor limit error breaks any transaction.
DependsOnSuccess
The name of an Atarc Process that must run successfully before the current Atarc Process for the current it to run. If an exception occurs within the specified apex class for the given process, ATARC will flag that process with a "Failed" status, process with a "Failed" status means they didn't run successfully.
Also, if no apex code exception happens but the process wants to flag itself with status "Failed" the method setFailed from the triggerContext parameter allows it to do it hence it means if other process has it listed in DependsOnSuccess it will not run .
DependsOnFailure
Represents the name of a process that must not run successfully before the current process for the current process to run. It works exactly the opposite of DependsOnSuccess.
Description
Text field, for general purpose usage. Recommended to give a brief description to each process so that its easy to understand what it does.
Category
Text field, to group several processes. Specially used with the bypass api, when a group of processes with the same category can be bypassed. In the following example it shows how to bypass all the processes with the 'category1' category.
public class RocketLauncher extends AsyncTriggerArc.AsyncTriggerArcProcessBase {
protected override object execute(AsyncTriggerArc.AsyncTriggerArcContext triggerContext){
triggerContext.bypass('category','category1');
return null;
}
}
Debug
Checkbox/Boolean switch to turn on/off. If true, the method debug of the triggerContext parameter will print the given message into the debug log. If false, this method won't do anything. This is very helpful as provides capability of making debug messages silent for specific processes when debugging.
public class RocketLauncher extends AsyncTriggerArc.AsyncTriggerArcProcessBase {
protected override object execute(AsyncTriggerArc.AsyncTriggerArcContext triggerContext){
triggerContext.debug('Running the Atarc Process...');
return null;
}
}
debugLevel
Text field. If Debug is set to true, this field will tell the system the level of debug. The possible options are the following:
- NONE
- ERROR
- WARN
- INFO
- DEBUG
- FINE
- FINER
- FINEST
Override Loop Limit
Checkbox/Boolean switch to turn on/off. If true, the LoopLimit field is used to control how many times the process can be executed when trigger recursion is encounter in a transaction.
LoopLimit
Numeric field to control how many times the process can be executed within recursive transaction only if "Override Loop Limit" is checked, if not then "ATARC Global Settings" custom settings controls this or from the code using triggerContext.LoopLimit by the process itself allow the process to be executed n times.
public class RocketLauncher extends AsyncTriggerArc.AsyncTriggerArcProcessBase {
protected override object execute(AsyncTriggerArc.AsyncTriggerArcContext triggerContext){
triggerContext.LoopLimit = 2;
return null;
}
}
ATARC Process Availability Rule custom metadata type
With this custom metadata type you can control Atarc Processes execution dynamically based on the running user properties.
Fields
ATARC Process Availability Rule Name
The name of the rule, this field is unique (regular DeveloperName field on custom metadata types).
ATARC Process Setting
The specific ATARC Process Setting record related to the availability rule. This is the Atarc Process the rule is being applied to.
Availability
What the rule is enforcing. Possible values are:
Available
Unavailable
When the value Available is selected and General Availability is unchecked in the related ATARC Process Settings, the related Atarc Process will only be executed if the running user meets the availability rule's criteria.
When the value Unavailable is selected and General Availability is checked in the related ATARC Process Settings, the related Atarc Process will NOT be executed if the running user meets the availability rule's criteria.
Custom Scope Filter
Checkbox/Boolean switch to turn on/off. Only valid when the Scope field is "User". If true the field Custom Scope Filter Value becomes required, and the value provided to Custom Scope Filter Value becomes the relevant criteria the running user should meet.
Custom Scope Filter Value
When Custom Scope Filter is checked the value in this field becomes the criteria the running user must meet for the availability rule to take effect.
The value accepted by this field is a list of json objects with three fields:
value this is the value use to compare against the field.
field, this is the field api name from the user object. It can be any field including custom fields.
op, this is the operator to apply to the field, the operators available are =, !=,<, <=, >, >=
The comparision expression is always starting with the value as the left side of the expression however the order inside the json object item can be anything.
The following example demonstrate the usage:
[{"value":"anyei", "op":"=", "field":"FirstName"}]
Multiple conditions are accepted, they are all anded:
[{"value":"anyei", "op":"=", "field":"FirstName"},
{"value":"atarc", "op":"!=", "field":"LastName"},
{"value":false, "op":"=", "field":"Absence__c"},
]
IsActive
Checkbox/boolean switch to turn on/off. If true is evaluated, else its not even evaluated.
Scope
Represents the range of options available for the running user criteria to meet. In combination with Scope Id Value field the availability rule will check the specific sobject record specified, the available options are:
Group
Permission Set
Profile
Queue
Role
User
Scope Id Value
The value in this field is compared against salesforce looking for the running user to either have or is included in the object selected by the Scope field.
For instance, if we select the value Profile in the Scope field and we provide a valid profile id in the Scope Id Value field, when the availability rule is being evaluated against the running user in order to take effect the running user has to have the profile id specified in the Scope Id Value field.
ATARC Global Settings custom settings
ATARC Global Setting is a hierarchy type of custom setting, you add a default organization value record and populate the Debug, SkipAll and LoopLimit fields.
Having an Organization Level record applies configuration for the entire organization and you can override that at Profile level or even User specific.
Fields
Debug
Checkbox/Boolean switch to turn on/off. If true, additional debug logs are added by the engine to the transaction which are independent from the executed processes. When false, these logs are not included in the transaction.
LoopLimit
Numeric field to control how many times the processes can be executed when trigger recursion is encounter in transactions, by default the value is 1 (recommended) but it can be changed.
This will be the default value used in each process execution unless specified in the ATARC Process Setting record when "Override Loop Limit" is checked and "LoopLimit" field has a value. Additionally, from the code using triggerContext.LoopLimit by the process itself allow the process to be executed n times.
SkipAll
Checkbox/Boolean swith to turn on/off. If true, all the processes are skip and no one is executed. This is a way to prevent all the processes from getting executed if needed.
General Availability
Checkbox/Boolean swith to turn on/off. If true, availability rules are not applied to user/profile/org associated with the settings.