4

On our Production Org, we have Performance Edition where we are allowed to have 2000 custom objects but we have around 500. Actually 676. Anyway. We are trying to migrate our internal production support project into DX and we are trying to push source of full sandbox into scratch org, but we receive a lot of errors including "reached maximum number of custom objects". It must be because we can create scratch org at most of Enterprise edition which supports 200 custom objects and we are definitely exceeding this limit.

We were thinking about splitting our internal org customization into separate artifacts, but it is tedious and complicated task, since we have a lot of interdependent functionality and we simply really struggle to separate functionalities we have since they depend on each other and as far as I understand, when you are working with artifacts, you can't have both Artifact A depend on Artifact B and vice versa, while in our case everything is really messed up and everything depend on everything.

Has anyone overcome the similar issue? What is the resolution to this?

2 Answers 2

3

From what I've heard, DX team is working on allowing us to specify limits like this in scratch orgs (e.g. increase maximum Role limit, Workflow Rule limit, etc), but we don't have a date as to when that will happen. Also, using Org Shape (still in pilot) should allow you to set the same limits you have in production.

For now, the two solutions are either: (a) get on Org Shape pilot, if you can, or (b) make multiple packages. What you'll probably need is a solution where you have several base packages that contain all the objects, and additional artifacts that contain your code, etc. While it's true that you can't have recursive dependencies, you can have an artifact exist in more than one package, as far as I've seen.

You'll want to read this blog post as it directly relates to your question, as well as the entire four-part series (links are in the post).

4
  • ok, that means that I would have to build dependency tree and determine first which objects depend on which object and select chunks of 200 object which depend only on themselves if I find such
    – Patlatus
    Jun 27, 2018 at 13:58
  • @Patlatus Yes, there's also a pilot for the Metadata Dependency API that might be useful for you, too. You should consider contacting your AE/CSR if you have one to talk to. Otherwise, it's possible to painstakingly do this (last time I tried, it took me like a month, but I hit other hard, unavoidable limits).
    – sfdcfox
    Jun 27, 2018 at 14:12
  • I need to ask my client if he agrees to join pilot program on shape, this might solve every problem we have
    – Patlatus
    Jun 27, 2018 at 14:53
  • One way to start is to pick a single app and start pushing to scratch org. First you gonna get messages of missing tabs, then flexipages then objects, etc. It's a laborious task, but might be worth it.
    – dzh
    Jun 28, 2018 at 10:55
0

This should be a good starting point to clean up your code base. Apologies in advance, if this answer does not directly adress your question. I believe that your problem (and hence, your question) arises from a cause that should be countered at the root and should not be worked-around. I encountered the circular dependencies problem with my Trigger and Apex REST frameworks which prevented me from neatly packaging my source code in different packages and disabled me from working on functionalities independently.

Most of the time, circular dependencies can be countered by following the SOLID principles (especially the D: "Dependency Inversion"). Many Frameworks I have seen contravene against these principles by demanding "only one trigger per object". If your trigger functionality depends on controlling the execution sequence in a "centralized" class, you essentially have no chance to install trigger-based functionality on the same object in different packages (because every package will provide its own trigger).

Refactoring your source code will let you de-couple your functionality and will allow you to conceptualize, develop and deploy non-circular dependend smaller packages (which will significantly increase the speed of your development and testing, and in the end reduce your time-to-market for your customizings). After you cleaned up all circular dependencies, you should be able to work on much smaller packages. This will indirectly solve your problem, since you will only push the handful of Custom-Objects you currently work on to your scratch org and not the whole "happy soup" of meta data.

I currently manage a much smaller org (100 users; 7 Unlocked Packages with 10k lines of source code) and finished the process a couple of months ago (took me maybe 1 to 2 months to re-implement virtually every customizing and migrate it to Unlocked Packages) but it was definitely worth the effort.

You must log in to answer this question.

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