We have a custom object - ExternalPortal Users which is a child of Opportunity and Contact.

Contact Path:

There is a checkbox on Contact - IsExternalPortalUser. If checked creates ExternalPortal Users record.

Opportunity Path:

When an opportunity is closed won. The Owner selects the contacts that need access to the portal and ExternalPortal users records are created for those contacts. We want the check off the box on contact to track if that contact is ExternalPortal User.


When we check off the checkbox(IsExternalPortalUser) on contact during opportunity path the trigger in Contact fires to again create a child record for this Contact. I know we can put some WHERE clause in the SOQL to prevent the class from creating one more record. But any other suggestions on how we can improve or remove this cyclic dependency?

  • 2
    Can you have the Opportunity trigger just set the Contact flag directly and allow the Contact trigger to handle creating the External Portal User records, instead of inserting them in the Opportunity trigger?
    – David Reed
    Jun 29, 2018 at 17:08
  • Do you have a trigger handler for these objects? If so, you can add a variable to the class to control recursion, otherwise, it might be time to look into setting a few handlers up, to get more control over how your records run. Jun 29, 2018 at 17:15
  • Can you explain why ExternalPortalUser__c is a child of the Opportunity object? If this dependency can be removed I think the suggestion from @DavidReed would be best. Also, what is the reason for supporting the ability to have more than one ExternalPortalUser__c record per contact?
    – Marty C.
    Jun 30, 2018 at 20:53

1 Answer 1


You could simply use a common static Boolean variable to keep track on if you need to do the logic:

public class CommonFlags {
  public static Boolean portalUsersProcessed { 
    get { return portalUsersProcessed == true; } 

In your Contact trigger:

if(!CommonFlags.portalUsersProcessed) {
  CommonFlags.portalUsersProcessed = true;
  // now create the portal users
  // Afterwards, turn off flag in case of bulk (>200) processing.
  CommonFlags.portalUsersProcessed = false;

And in your external portal users trigger, do the same (except, update the contacts). This way, there's no need for an extra check, because you only process them once. Other, more complicated arrangements are also possible, but I think this probably qualifies as the most simple fix you could choose to implement.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .