I have a problem statement where I need to store a list of some 40 Parent Objects Ids statically. Further, if any one of the Parent Object's child records goes higher then 45,000(which is calculated using the roll-up summary field on parent object) I need to replace that parent objects Id from this list with new object's Id. Earlier this could have been done by maintaining the same in custom setting record's field, as same is updateable through apex code. But as custom settings being depreciated, it is becoming challenging to do so. Following alternatives I have found but couldn't proceed with:

  1. Using Custom metadata type object record.As we can update the same through metadata API and deployments. But this requires metadata modify permission, which I cannot afford to give to my user.
  2. Thought of static resource, but DML cannot be performed on it.
  3. Custom labels, but cannot be updated.

If anybody has an alternative for this please share the same.

Business Scenario: For the creation of child object A we need parent object as a must. In some scenarios the parent object is present but on some, it is not. So they have created a list of dummy parent object which they maintain in the custom label and using round robin or random number logic they assign the parent object to child objects. But a huge number of child records are getting created, they are now getting 50,001 exceptions while querying the parent object. So they replace the parent Id from a label with new parent object's one, manually as soon as it reaches 48,000 or something to prevent the same 50,001 exceptions. But they have to do this manually. I need to automate the same.(Weird scenario)

When a child object A is created,an integration user(with whom the records are shared) performs some calculations based on values on A , and attach 3 more objects to it with some values(financial calculations).But for these caculations to be done and these new objects to be created , A must hold the parent object to it as mandatory.And this parent object is the dummy objects they have created.

  • 4
    Are you doing some kind of round-robin assignment to reduce data skew? Why not just use a picklist ('Active', 'Inactive') on the parent so you don't need a custom setting at all? – David Reed Nov 3 '18 at 18:41
  • @David Reed Thanks for quick reply. We could do that, the problem here is, in my case on daily basis, around thousands of these parent object gets created on production org. Also, the users might select this picklist value as active unknowingly, and then that object might be considered as well. It's a bit completed process as well. (I should update the question properly I guess). Yes, You were almost right regarding round-robin assignment, though we use, the random number for assignment. – Pankaj Andhale Nov 3 '18 at 19:04
  • 2
    To prevent data skew, you should really shoot for keeping the parent-to-child ratio no higher than 1 : 10,000. You can query up to 50k records, and that's the limit you're hitting, but going much beyond 10k in a parent-child relationship can cause performance issues. Possibly locking issues as well, if you don't have a public read/write sharing model on the parent object. This blog post is about the Account object specifically, but the same concept applies: developer.salesforce.com/blogs/engineering/2012/04/… – Shane Steinfeld Nov 3 '18 at 19:49
  • 2
    Without going into anything business-specific, can you give us a little more inofrmation about what the two objects represent, and why the parent-child relationship is important? I'm wondering if there isn't a better way to handle the relationship if records that need a (temporary) exception to that rule are created so frequently. – Shane Steinfeld Nov 3 '18 at 19:55
  • 1
    Custom Settings are not being deprecated. Where did you read this? – CommonCoreTawan Nov 3 '18 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.