I don't believe there's a limit to the number of close codes beyond what you can have for the field type or rows on the choices table.
As for "best practice" - the only one is that you use them with intent. The purpose is to measure & report on what was done. If you're not measuring or reporting on it, best practice would be to not use it (at least not with intent).
If you are intent on measuring incident outcome, your business will determine what defines a "work around" as opposed to "resolution" for instance - but imo it's kinda self-explanatory with regards to the use of the OOB incident codes (see below). However, when it comes to request task closure, it's much more dependent on the specific business processes. "Closed Complete" would theoretically indicate that the customer got exactly what they requested as described...but it would depend on the threshold of what the business defines as "as described" -- sometimes it's acceptable to skip some task, but still close complete (perhaps the task is optional). One size fits all or "best practice" for task/request closure is less straight forward (needs business process discussion) than it is for Incident Management (as defined by ITSM best practices like ITIL).
OOB incident close codes:
1.) Duplicate = this is not a unique incident. This exact incident was already reported and an incident record already exists, so the data from this one should not be counted as unique, nor should it inform process actions (Incident Management process, not platform process). This is different from 2 separate users both reporting the same issue - IE. if customer "Billy" reports "Wifi down" to IT tech "Jill" and Jill makes INC001234 about it...then "Susan" reports "wifi down" to IT tech "Jill" and Jill makes INC001235, they are not duplicates. However, if Billy also mentions this to IT tech "Shamsul" and then Shamsul creates INC001236 for Billy wifi down, that one is a duplicate of INC001234. Arguably they could be different if one is for Billy's laptop and one is for Billy's mobile device (technically different CIs) - but again, this comes down to business decisions related to how you want to report against the reliability of the wifi service (would you want to report on devices affected or users affected?)...not related to "best practice".
2.) Known error = this is when you have accepted an error and decided to not fix it. You may have an open problem ticket for the known error, but you aren't intending to link the incident to that (else, in that scenario you would probably rather have it on hold pending problem outcome). This would be used when you are not driving any process actions from this and simply do not want to report on this or measure this client impact as an incident, but do want the client to be recorded as having inquired about the known error. Often you can drive business process that will automatically send a KB article to a user that describes a work-around, when this type of resolution code is used.
3.) No resolution provided = you may want a way to close an incident as "resolved", when it isn't actually resolved. You may want to stop business process, but can't say that the incident is actually resolved (perhaps it isn't). This could be used for when a customer requests to opt out of the remainder of an incident management case, after reporting it (cancelling the incident, but no info is known about resolution).
4.) Resolved by caller = customer/caller informs you that they have resolved the issue and no longer need to be involved with the incident management process. This could be due to T0 self-service tools - or the customer "taking the reigns themselves" and performing non-prescribed technical actions to fix their own issue.
5.) Resolved by change = a change performed by IT fixed the issue. This is specifically referring to a technical change that went through the Change Management process. The intersection of this process with Incident Management and Problem Management needs to be defined by your business.
6.) Resolved by problem = fixing a problem, also resolved the incident. This is specifically referring to a technical problem that went through the Problem Management process. The intersection of this process with Incident Management and Change Management needs to be defined by your business.
7.) Resolved by request = fulfilling a request, resolved the incident. This is used in the case where a client just needed to request something and "now it works" - often this isn't really seen as an incident and is akin to a "customer education" type of resolution. "Hey did you know that you can just install this software and you won't have that problem -- points to software install form".
8.) Solution provided = this is for when Incident Management goes exactly as intended. Incident is reported, recorded, triage and troubleshooting performed, solution provided, solution works, incident resolved with no anticipation of it needing to be addressed again in the future.
9.) Work around provided = this is for when you resolve an incident with a temporary solution and would provide a better solution if one was available. Often there is an intersection here with either Problem Management or Request Fulfilment. This is different from "solution provided" as it distinguishes it as being a "less than ideal" solution with or without intent to follow-up or perform more actions in the future - usually the intent is there to do something better in the future and remove the work-around, but again, that's up to the business to decide.
10.) User error = this is when a customer reports an incident, but they are actually making a mistake - expecting something to happen, which intentionally doesn't...or complains about a feature, calling it a bug. This is also something that is a bit arguable (like with resolved by request) as to if this is an incident or not -- if the client actually knew exactly how this was supposed to work, there wouldn't be an incident and they'd use it as intended -- or put in a feature request for change, rather than report an incident.
I don't believe there's a limit to the number of close codes beyond what you can have for the field type or rows on the choices table.
As for "best practice" - the only one is that you use them with intent. The purpose is to measure & report on what was done. If you're not measuring or reporting on it, best practice would be to not use it (at least not with intent).
If you are intent on measuring incident outcome, your business will determine what defines a "work around" as opposed to "resolution" for instance - but imo it's kinda self-explanatory with regards to the use of the OOB incident codes (see below). However, when it comes to request task closure, it's much more dependent on the specific business processes. "Closed Complete" would theoretically indicate that the customer got exactly what they requested as described...but it would depend on the threshold of what the business defines as "as described" -- sometimes it's acceptable to skip some task, but still close complete (perhaps the task is optional). One size fits all or "best practice" for task/request closure is less straight forward (needs business process discussion) than it is for Incident Management (as defined by ITSM best practices like ITIL).
OOB incident close codes:
1.) Duplicate = this is not a unique incident. This exact incident was already reported and an incident record already exists, so the data from this one should not be counted as unique, nor should it inform process actions (Incident Management process, not platform process). This is different from 2 separate users both reporting the same issue - IE. if customer "Billy" reports "Wifi down" to IT tech "Jill" and Jill makes INC001234 about it...then "Susan" reports "wifi down" to IT tech "Jill" and Jill makes INC001235, they are not duplicates. However, if Billy also mentions this to IT tech "Shamsul" and then Shamsul creates INC001236 for Billy wifi down, that one is a duplicate of INC001234. Arguably they could be different if one is for Billy's laptop and one is for Billy's mobile device (technically different CIs) - but again, this comes down to business decisions related to how you want to report against the reliability of the wifi service (would you want to report on devices affected or users affected?)...not related to "best practice".
2.) Known error = this is when you have accepted an error and decided to not fix it. You may have an open problem ticket for the known error, but you aren't intending to link the incident to that (else, in that scenario you would probably rather have it on hold pending problem outcome). This would be used when you are not driving any process actions from this and simply do not want to report on this or measure this client impact as an incident, but do want the client to be recorded as having inquired about the known error. Often you can drive business process that will automatically send a KB article to a user that describes a work-around, when this type of resolution code is used.
3.) No resolution provided = you may want a way to close an incident as "resolved", when it isn't actually resolved. You may want to stop business process, but can't say that the incident is actually resolved (perhaps it isn't). This could be used for when a customer requests to opt out of the remainder of an incident management case, after reporting it (cancelling the incident, but no info is known about resolution).
4.) Resolved by caller = customer/caller informs you that they have resolved the issue and no longer need to be involved with the incident management process. This could be due to T0 self-service tools - or the customer "taking the reigns themselves" and performing non-prescribed technical actions to fix their own issue.
5.) Resolved by change = a change performed by IT fixed the issue. This is specifically referring to a technical change that went through the Change Management process. The intersection of this process with Incident Management and Problem Management needs to be defined by your business.
6.) Resolved by problem = fixing a problem, also resolved the incident. This is specifically referring to a technical problem that went through the Problem Management process. The intersection of this process with Incident Management and Change Management needs to be defined by your business.
7.) Resolved by request = fulfilling a request, resolved the incident. This is used in the case where a client just needed to request something and "now it works" - often this isn't really seen as an incident and is akin to a "customer education" type of resolution. "Hey did you know that you can just install this software and you won't have that problem -- points to software install form".
8.) Solution provided = this is for when Incident Management goes exactly as intended. Incident is reported, recorded, triage and troubleshooting performed, solution provided, solution works, incident resolved with no anticipation of it needing to be addressed again in the future.
9.) Work around provided = this is for when you resolve an incident with a temporary solution and would provide a better solution if one was available. Often there is an intersection here with either Problem Management or Request Fulfilment. This is different from "solution provided" as it distinguishes it as being a "less than ideal" solution with or without intent to follow-up or perform more actions in the future - usually the intent is there to do something better in the future and remove the work-around, but again, that's up to the business to decide.
10.) User error = this is when a customer reports an incident, but they are actually making a mistake - expecting something to happen, which intentionally doesn't...or complains about a feature, calling it a bug. This is also something that is a bit arguable (like with resolved by request) as to if this is an incident or not -- if the client actually knew exactly how this was supposed to work, there wouldn't be an incident and they'd use it as intended -- or put in a feature request for change, rather than report an incident.
