<p>Brad mentions there's no limitations on entry types, though whether it's a good idea long term for maintainability and UI purposes is another story.</p>
<p><a href="https://craftcms.com/docs/3.x/entries.html#entry-types" rel="nofollow noreferrer">Entry Types</a> are the most useful when your content is quite different among them but you still want to keep entries together in the same section.</p>
<p>For example, in a News section, you might have a <code>Link to Page</code> entry type where you link off to different websites and a <code>Blog Entry</code> type where they're just regular entries. (John Gruber's Daring Fireball site is a good example of this.</p>
<p>In my experience, when a user starts to see a dozen or so entry types, it can start to become pretty overwhelming... here's what 50 of them staring you in the face might look like:</p>
<p><img src="https://i.sstatic.net/M9Gig.png" alt="50 entry types" /></p>
<p>Entry types are useful because they each have <em>their own set of fields.</em></p>
<p>However, from a maintainability standpoint, let's say you want to add or move a field in every report. Doing it to 2 or 3 entry types is pretty straightforward but doing it consistently to 50? Way harder—whether you're using YAML files or the GUI!</p>
<p>The 80/20 rule might be helpful here: I'm guessing 80% of the reports generated are probably going to fall into 20% of their types. That just narrowed down the number of entry types to 10.  Maybe you add a few other more common ones plus a catch-all &quot;Other...&quot; entry type or something.</p>
<p>Unless your client is also a fellow developer/designer, they don't want to be adding fields and sections to the backend unless absolutely necessary.</p>
<p>If I were you, I might ask you client: what's different about each report? What's the same? You'll come across some good answers which can help you and your client model this nicely.</p>
<p>That could lead you to use something like Categories instead, where it's very easy to add new ones. If the report types are more like filters, they also will show much nicer in the GUI.</p>
<p>And maybe you do need some report types to hide and show different fields but are otherwise pretty similar. You might consider doing this with, say, the <a href="https://github.com/mmikkel/Reasons-Craft3" rel="nofollow noreferrer">Reasons</a> plugin.</p>
<p>Food for thought!</p>

CC BY-SA 4.0
2020-09-02T21:56:33.937Z
Of course, you have a better answer. :)
Brad Bell
CC BY-SA 4.0
2020-09-03T15:44:50.963Z
Thanks for your super detailed response! Each of the reports have some common fields but they also have unique fields. Reports like Discipline Notice, Hazard or Deficiency, Meeting Notes. All these Report entries are created/edited by users in the front end. We're currently using a form plugin but some of the field types are limited and having core Craft fields would be useful.
Amanda Lutz
CC BY-SA 4.0
2020-09-03T16:09:21.757Z
@AmandaLutz Sounds like a fun project! FWIW nobody gets these things right the first time either. You might consider trying a few options on for size and seeing what fits.
RitterKnight
CC BY-SA 4.0
2020-09-02T20:51:51.687Z
2020-09-02T20:51:51.687Z
RitterKnight
<p>There's no hard-coded limit for content in Craft (sections, entry types, entries, fields, etc.).</p>
<p>It'll largely depend on how you're using that content in your templates and what type of environment the installation is running on (physical server resources, caching strategies, etc.)</p>
<p>We've seen installations with some pretty complex information architectures spread across 50+ &quot;sites&quot; and tens of millions of elements (entries, users, assets, categories, etc.)</p>

CC BY-SA 4.0
2020-09-02T20:25:52.683Z
2020-09-02T20:25:52.683Z
Brad Bell
<p>Is there a limit to the number of different entry types a section can have? For this project I might need 50+.</p>
<p>I think I need more content to meet the quality standards so I'll explain: my client wants to create multiple reports for her customers to fill in. My client is comfortable with craft backend and knows how to create fields/sections/etc. I want to keep all the report entries together. Ergo a Reports section with a different entry type for each report.</p>

<entry-type>
Max # of entry types?
# Max # of entry types?

(Asked by: username_0 on 2020-09-02)

Is there a limit to the number of different entry types a section can have? For this project I might need 50+.

I think I need more content to meet the quality standards so I'll explain: my client wants to create multiple reports for her customers to fill in. My client is comfortable with craft backend and knows how to create fields/sections/etc. I want to keep all the report entries together. Ergo a Reports section with a different entry type for each report.

**Tags:** entry-type

---

## 2 answers

### Answer by username_1 on 2020-09-02. Score: 4 | Accepted answer

Brad mentions there's no limitations on entry types, though whether it's a good idea long term for maintainability and UI purposes is another story.

[Entry Types](https://craftcms.com/docs/3.x/entries.html#entry-types) are the most useful when your content is quite different among them but you still want to keep entries together in the same section.

For example, in a News section, you might have a `Link to Page` entry type where you link off to different websites and a `Blog Entry` type where they're just regular entries. (John Gruber's Daring Fireball site is a good example of this.

In my experience, when a user starts to see a dozen or so entry types, it can start to become pretty overwhelming... here's what 50 of them staring you in the face might look like:

![50 entry types](https://i.sstatic.net/M9Gig.png)

Entry types are useful because they each have *their own set of fields.*

However, from a maintainability standpoint, let's say you want to add or move a field in every report. Doing it to 2 or 3 entry types is pretty straightforward but doing it consistently to 50? Way harder—whether you're using YAML files or the GUI!

The 80/20 rule might be helpful here: I'm guessing 80% of the reports generated are probably going to fall into 20% of their types. That just narrowed down the number of entry types to 10. Maybe you add a few other more common ones plus a catch-all "Other..." entry type or something.

Unless your client is also a fellow developer/designer, they don't want to be adding fields and sections to the backend unless absolutely necessary.

If I were you, I might ask you client: what's different about each report? What's the same? You'll come across some good answers which can help you and your client model this nicely.

That could lead you to use something like Categories instead, where it's very easy to add new ones. If the report types are more like filters, they also will show much nicer in the GUI.

And maybe you do need some report types to hide and show different fields but are otherwise pretty similar. You might consider doing this with, say, the [Reasons](https://github.com/mmikkel/Reasons-Craft3) plugin.

Food for thought!

> **Comments:**
> **username_2**: Of course, you have a better answer. :)  
> **username_0**: Thanks for your super detailed response! Each of the reports have some common fields but they also have unique fields. Reports like Discipline Notice, Hazard or Deficiency, Meeting Notes. All these Report entries are created/edited by users in the front end. We're currently using a form plugin but some of the field types are limited and having core Craft fields would be useful.  
> **username_1**: @AmandaLutz Sounds like a fun project! FWIW nobody gets these things right the first time either. You might consider trying a few options on for size and seeing what fits.  

---

### Answer by username_2 on 2020-09-02. Score: 0

There's no hard-coded limit for content in Craft (sections, entry types, entries, fields, etc.).

It'll largely depend on how you're using that content in your templates and what type of environment the installation is running on (physical server resources, caching strategies, etc.)

We've seen installations with some pretty complex information architectures spread across 50+ "sites" and tens of millions of elements (entries, users, assets, categories, etc.)


---

