Difference between Resolved and Closed?

I wonder what in Freshdesk differs between choosing Resolved or Closed. Is this just to be used to organize the work better among agents or does it have any practical influence?

Best Answer

Hi Mario


"Resolved" : The Agent or technician believes the issue is resolved

"Closed" : The end user has acknowledged that the resolution is to their satisfaction


Thanks and regards,

4 people have this question


Hi Mario


"Resolved" : The Agent or technician believes the issue is resolved

"Closed" : The end user has acknowledged that the resolution is to their satisfaction


Thanks and regards,

Dumb question but I will ask...
If a ticket sits with no response from the customer, the agent can close the ticket and it will not be counted under the "Overdue" bucket?


Maybe i'm  missing how resolved counts in reports. If you update a ticket to resolved, but its changes to closed later, then does this show closed in reports, or still shows resolved? The whole closed and resolved thing has been confusing for our whole department and how it counts in reports. Can you clear this up for me please?

Hey Terry, 

In reporting, we calculate "Resolved" and "Closed" in similar manner and we account this under "Tickets Resolved" count. 

Let me know if you have more questions on this. Will be glad to clear them up!


So I want to be sure I understand the Freshdesk intended use of these states so that I can count on accurate metrics - Freshdesk please confirm this is correct in terms of ticket flow...

1. Ticket Opened and some troubleshooting occurs - maybe several back and forth messages between agent and customer.

2. Agent believes the reply he/she is writing will solve the problem so sends the reply with ticket status RESOLVED.

3. Customer views reply, it solves the issue, and sets the ticket status to CLOSED.


1. is there a "this solved my issue" button/link the customer can use to simply/quickly set the ticket to CLOSED?

2. can a workflow be written such that if a ticket stays in a resolved state for X days a reminder is sent to customer, and then again at X+5 days to auto-close the ticket if no customer response?

3. Is there a way to prevent a CLOSED ticket from being reopened once it is more than 30 (contiguous) days in the closed state?

If you going to have two ticket states that differ only in their perspective (customer versus agent), there must be some logical benefit to it - and reporting and views should account for the fact that (in your example) RESOLVED is NOT equal to CLOSED. So for example a view of "all open tickets" would include resolved tickets since the customer has not acknowledged the solution works.

@Rusty.wilson very good questions. Any way we can set tickets to close after they have been resolved for X amount of time?


1. The Customer will have a button using which they can mark a ticket as closed on the portal. See this screenshot below :

2. You can set up a Supervisor rule to automatically close tickets without customer response after a defined period of time , say 3 days. 

Conditions :  

Status is resolved 

Hours since resolved greater than 72 hours ( 3 days ) 

Actions :

Set status as Closed 

3. It is not possible to prevent a ticket from being re-opened when a customer responds after specific time period but can create a new ticket based on the latest response immediately .


@ Aravind - Thank you for clarifying this matter!

@John : You're welcome any time :) 

@Arvaind: I can test this out but it looks like you are speaking to these topics above and I don't understand your meaning. Can you please clarify by answering these questions:

- If a closed ticket is responded to by the customer does it open back up or spawn a new ticket?

- Is there a period after which replying to a closed ticket won't re-open it but will instead spawn a new ticket?

@Aravind - please could you answer the above question from Rich Lorenzo. Thanks

So I've poked around a bit more in the "Observer" rules and I discovered a rule "Automatically reopen tickets when the customer responds". With the following description: When a requester replies to a ticket in any state (pending, resolved, closed or a custom status), its status is changed back to open.

I've inherited my Freshdesk from somebody else so I'm not sure if this is a default rule or something my successor created himself. But I think this answers my question above. Essentially in my Freshdesk Resolved and Closed are the same thing based on the way this Observer rule is configured. And I could make tickets stay closed by removing the "Closed" state as a condition from this rule.

This would be handy for me because we often escalate tickets to JIRA with the integration app and then have them continually re-opened in Freshdesk every time a comment is posted to the JIRA. (We have JIRA comments posting as public in Freshdesk since we're supporting internal customers.) So I think if we wanted to avoid a ticket opening back up when a JIRA comment hits the ticket I could remove the Closed state as a condition from this rule. However, this creates another problem for if/when people reply to old ticket threads...if the ticket doesn't open back up we'll completely never see their comment.

I don't see a good solution that meets our requirements here. And coming from a Zendesk this is frustrating because all of these solutions are not only built in but very readily apparent.


i am new to freshdesk and i have few questions, i  have a task to do a summary report about freshdesk tickets, eg: how may open tickets, how many resolved, how many pending, how many closed..etc, by the end of the day, so i filter tickets created within last 30 days and sort tickets by last modified, question is last week there were 48 resolved tickets and when we check this week it was 19, is there any reason why this resolved tickets are reducing??? pls help


Hi Amila,

This could be because of the default supervisor rule which would move the resolved ticket to closed status after 24/48 hours. 

So , please make sure you take the closed tickets into consideration as well, when you look into this.