The typical way to handle editing/deleting a record would be to use the sharing model, or what is also sometimes referred to as record-level security.
Record access has 5 types of permission.
- Transfer Ownership
I remember these by the acronym VESTD.
The owner of the record is VESTD and can perform all of these actions (depending on their object permissions of course. If their profile does not grant Delete perms, they cannot delete, for instance. You can also make a queue be an owner. If a queue is an owner, then every user that is member of the queue is VESTD.
Finally, if you're not the owner, the most you will ever be able to do with that record is View and Edit. Share, Delete, and Transfer Ownership are always only reserved for Owner.
You can also go to Setup > Security > Sharing Settings and set the organization wide default sharing for an object. Custom objects support three levels: Private, Public Read-only, and Public Read/Write.
Finally, administrators always have full access to data in the org. Their only restriction for data visibility is field security and encrypted fields. But that doesn't apply here.
So taking all that in, here is how I would use this no-code solution to solve your problem.
- Set the org-wide default sharing for Call__c to Public Read-only.
- Create a new queue called Call is Complete. Add no users to the queue.
- Create a workflow rule to do the following so that when Call__c is saved and Status__c is Complete, the Call is Complete queue is set in the Owner field.
This will prevent anyone from editing or deleting the Call__c record or either of its children once the "Complete" value is set in the Status__c field.
Note: because of making
Call_Asset__c related to
Call__c with master-detail relationships, you cannot use the sharing model to only set those to be editable or not. They will always follow the sharing permissions of the parent record. So to use the sharing model independently on these children, you would need to change the relationships to Lookup relationships. But don't take that step lightly.
I would advise you to do a lot more reading on the sharing model. It is purpose built for exactly what you are trying to do. Even if this solution won't work, trying to build anything in Force.com without understanding sharing will make you solve problems in ways you shouldn't. Start here. Then go to salesforce help and search for "sharing" and read as much as you can. There are also several articles and white papers on sharing in the salesforce developer portal.
For more on understanding relationships, this isn't a bad page to read.
Sharing and relationships go hand in hand, so you will need to understand them both to solve your problem in the best possible way.