Currently I do the following to create a one-to-one relation between two objects:

  1. Create a lookup field on the child
  2. Create a unique field on the child, and hide this field from all page-layouts
  3. Write a workflow, for any change of the lookup field, to copy that value from the lookup field into the unique field

This process has many overheads:

  1. Extra field is required
  2. Unique criteria is utilized (we only get 3 unique fields per object)
  3. Workflow is used

What other ways are there to create a one-to-one relation between two objects?

  • 1
    You forgot another overhead: lack of a good error message! Great question here... Commented Oct 13, 2013 at 17:17

3 Answers 3


another way to do is... create a master detail relationship and than on master create a roll up summary field of child with count. then you write validation on rule rollup summary field to check for >1 .. so it will give you error if it has more than one record for same master detail relation values..

one to one created...

  • What's unfortunate with this solution (and others in this thread) is that the user will only find out about this validation rule after they've spent (a lot of?) time creating this custom object, only to be rejected when they attempt to save it. Looks like this is the only option tho, and thank you! It saved me a lot of time. Commented May 14, 2014 at 18:05

Just been told, by a colleague, about another process:

  1. Create lookup fields on both objects, to each other
  2. 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 (i.e., already having a one-to-one relation)

This trigger doesn't iterate through the record list, hence is a scalable solution.

  • 3
    Now making the solution more robust and removing the trigger from your design .You can actually have a validation with say if lookupId not null then dont allow to change . Commented Jan 16, 2013 at 7:41

The solution that you mentioned is commonly followed as its out of box .The idea that you mentioned is documented in this blog very well


The other solution is very obvious that's the trigger .Just checking if the child record already exists for a parent ,not allowing the user to create the other one unless until first child record id deleted .But downfall its custom coding.

Next way is why not merge the fields of both the objects and make a single object .Note this i will consider when i have to go for one to one between custom objects .If standard like Account and contact then i would prefer outofbox one.

  • Thanks for the reply. I am avoiding the trigger-solution since it needs iteration (for-loop) through the record list, which will impact performance in case record count is high. Commented Jan 16, 2013 at 6:10
  • 1
    agreed..I mentioned its not the greatest technique but just an alternative..If anything is possible through out of box i will prefer that.. Commented Jan 16, 2013 at 7:29

You must log in to answer this question.

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