Basically Salesforce offers two types of relationship:
One To Many Relationship
Many To Many Relationship (Using the concept of Junction object)
Sometimes we may need One To One relationship, But unfortunately Salesforce doesn’t allow any direct methodology to build One To one relationship.
Let’s consider the scenario that we want to establish a One to One relationship between two custom objects Employee__c and PAN_Card__c.
So, here are few ways to implement One To One relationship between two objects in Salesforce. We can achieve this by using configuration only and can also achieve this by using code to make it more scalable.
Option 1:
Create a lookup field on PAN_Card__c to Employee__c.
Create a custom field on the PAN_Card__c object and make the field unique. This field would be used to hold the ID of the associated Employee__c. Hide this field from all page layouts.
Create a Workflow rule on PAN_Card__c. For any change of the lookup field on PAN_Card__c object, update the custom field on the PAN_Card__c object with the value of the associated Employee Id.
We have established a one to one relationship between PAN_Card__c and Employee__c. When we try to add a second PAN_Card__c to the Employee__c, the “unique” constraint would be violated and an error would be thrown. This approach will work on both standard and custom object.
Option 2:
Create a master detail relationship on PAN_Card__c to Employee__c object.
Create a roll up summary field on Employee__c object of PAN_Card__c with count type.
Create a validation rule on Employee__c object rollup summary field to check if count > 1.
In this way also, We have established a one to one relationship between PAN_Card__c and Employee__c. So it will throw an error if Employee__c has more than one PAN Card.
Option 3:
Create lookup fields on both objects PAN_Card__c and Employee__c, to each other.
Write triggers, for any change on these lookups, to either copy the record ID into the other object’s lookup field when the other object’s lookup field is empty, or disallow the change to the original record when the other object’s lookup field is already populated with a different ID from the original record.
This is already having a one-to-onePassport relation.
Option 4:
Create a trigger on PAN_Card__c object to check if the PAN Card record already exists for an Employee. If it exist, then throw an error, else allow the user to create.
Here is the example for Employee__c and PAN_Card__c object:
trigger PANCardValidation on PAN_Card__c (before insert, before update) {
Set<id> employeeIds = new Set<id>();
Map<id, Employee__c> mapEmployee = new Map<id, Employee__c>();
for (PAN_Card__c p : trigger.New) {
employeeIds.add(p.Employee__c);
}
List<Employee__c> lstEmployee = [SELECT Id, Name FROM Employee__c WHERE Id IN : employeeIds];
if (!lstEmployee.isEmpty()) {
for (Employee__c emp : lstEmployee) {
mapEmployee.put(emp.Id, emp);
}
for (PAN_Card__c p : trigger.New) {
if (mapEmployee.containsKey(p.Employee__c)) {
p.addError('A PAN Card already exist for the employee - ' + mapEmployee.get(p.Employee__c).Name);
}
}
}
}
All triggers define implicit variables that allow developers to access runtime context.
These variables are contained in the System.Trigger class:
Variable
Usage
isExecuting
Returns true if the current context for the Apex
code is a trigger, not a Visualforce page,
a Web service, or an executeanonymous()
API
call.
isInsert
Returns true if this trigger
was fired due to an insert operation, from the Salesforce user
interface, Apex,
or the API.
isUpdate
Returns true if this trigger
was fired due to an update operation, from the Salesforce user
interface, Apex,
or the API.
isDelete
Returns true if this trigger
was fired due to a delete operation, from the Salesforce user
interface, Apex,
or the API.
isBefore
Returns true if this trigger
was fired before any record was saved.
isAfter
Returns true if this trigger
was fired after all records were saved.
isUndelete
Returns true if this trigger
was fired after a record is recovered from the Recycle Bin (that is, after an undelete operation from the Salesforce user
interface, Apex,
or the API.)
new
Returns a list of the new versions of the sObject records. This
sObject list is only available in insert, update,
and undelete triggers, and the
records can only be modified in before triggers.
newMap
A map of IDs to the new versions of the sObject records. This map
is only available in before
update, after
insert, after
update, and after
undelete triggers.
old
Returns a list of the old versions of the sObject records. This
sObject list is only available in update and delete
triggers.
oldMap
A map of IDs to the old versions of the sObject records. This map
is only available in update and delete triggers.
size
The total number of records in a trigger invocation, both old and
new.
In certain scenarios, we need to make the webservice callout from the apex trigger to call an external webservice. We cannot call external web services synchronously from triggers, because calling a web service synchronously from triggers will hold up the database transaction until the callout completed. This will impact performance for other transactions. In this scenario we can invoke callouts from triggers by encapsulating the callouts in @future methods. Here is an example, how to invoke webservice callouts from trigger.
Apex Class:
public class LeadTriggerHandler {
@future (callout=true)
public static void sendLeadInfo(string firstName, string lastName, string email) {
try{
HttpRequest request = new HttpRequest();
HttpResponse response = new HttpResponse();
Http http = new Http();
request.setEndpoint('Your Endpoint URL');
request.setHeader('Content-Type','application/json');
request.setMethod('POST');
request.setBody('fname='+EncodingUtil.urlEncode(firstName, 'UTF-8')+'&lname='+EncodingUtil.urlEncode(lastName, 'UTF-8')
'&email='+EncodingUtil.urlEncode(email, 'UTF-8'));
request.setCompressed(true);
response = http.send(request);
if (response.getStatusCode() == 200) {
System.debug('Response-' + response);
}
}
catch(System.CalloutException e){
System.debug('Error-' + e.getMessage());
}
}
}
Apex Trigger:
trigger LeadTrigger on Lead (after insert) {
for (Lead objLead : Trigger.new) {
//make webservice callout
LeadTriggerHandler.sendLeadInfo(objLead.FirstName, objLead.LastName, objLead.Email);
}
}
trigger AccountTrigger on Account (before delete, before update, before insert, after insert, after update) {
if (trigger.isDelete) {
for (Account acc : trigger.old) {
acc.addError('You cannot delete account records');
}
}
}
I had a requirement to restrict multiple approval for a single user to a single record. There were multiple steps of approval process and the approver may be in different queue or as a manager for a user.
So, I implemented it using a trigger. In this article I’ll demonstrate how to implement it.
Here Application__c is the object, on which 3 steps approval process has implemented.
A custom check box field Check_Approver__c has set value to true, in all 3 steps field update action.
In below trigger I filtered the ProcessInstanceStep object records with current user Id in ActorId and the object Id (here object Id means record Id) in ProcessInstance.TargetObjectId.
If an User will approve or reject a record, then the SOQL query will return a single record.
If the SOQL query return a record, then trigger will throw an error message.
Trigger source code:
trigger ApplicationTrigger on Application__c (before Update)
{
if(trigger.isUpdate){
Id currentUserId = UserInfo.getUserId();
for(Application__c sf: trigger.new){
if(sf.Check_Approver__c == true){
List<processinstancestep> existingApprovals = [SELECT ActorId
FROM ProcessInstanceStep WHERE ProcessInstance.TargetObjectId = :sf.Id
AND (StepStatus = 'Approved' OR StepStatus = 'Rejected')
AND ActorId = :currentUserId];
if(existingApprovals != null){
if(existingApprovals.size() > 0){
sf.addError('You have already approved or rejeted the record.');
}
}
}
}
}
}
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptReject