Mathematically speaking, it's not infinite, as JIRA would eventually start trying to use numbers that the database and language can't really handle, but you'll never get anywhere near there before other things fail - humans not being able to read the list of fields because it would take them months, server/browser not able to render pages because they're simply too long, and so-on.
So, although there's no hard maximum, good practice dictates that you don't want to let your system get too complex because it'll be unmanageable and unhelpful when you've got "too many".
A lot of my history with JIRA has been "tidy up the mess made by previous admins" and one of the themes there is "too many custom fields". The worst one took nearly 1,000 fields down to around 200 and the team had a goal of 100 by the time I left (technically, no problem, but the difficulty was getting the users to accept that their fields weren't actually of any use, or really could be merged with others with similar names)
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs