SLA policy improvements

Thanks for the feedback, Craig. I will discuss this with the team and see if we can add this to the roadmap. 

Hi Could I get an update on this please as is a feature that would be a great benefit to us :)

Any news of if this was added to the roadmap? and if so a potential ETA? this feature would be really beneficial to us and our reporting

Hi Craig,

Sorry for the delay in replying. Improvements in this regard are coming, but it will be long before it happens. I'm afraid I am not in a position to give you a concrete ETA. 

Hi Narain,

Any movement on this in the roadmap chart :)

Any further news on this, it would be great if you could add individual requesters against and SLA type rather that whole departments

Hi Craig,

I hit a similar roadblock during implementation and wanted to share my ad-hoc solution that, while not exactly elegant, has at least got the job done.

We wanted to have our SLAs running of some custom fields that we created (Scope, Area of Impact, Level of Impact), and since these aren't built-in FS doesn't have any way to run SLA logic off them. Instead, I created a number of SLA options based on the existing options (type and what have you), then created rules in both Dispatch'r (for new tickets) and Observer (for existing tickets) to set the appropriate priority. For example, an incident with Scope = Global, Area of Impact = Work, Level of Impact = No Impact should get the "High" priority. This is easily done through an dispatch'r/observer rule. The trick (and this is where it becomes inelegant) is associating that with an appropriate SLA policy. To do that, I picked a built-in field that I wasn't really using (Department) and set THAT as part of the observer rule as well. Thus, I could build as many SLAs as I wanted, using Department as the selector, and set that as needed through my rules and end up with the correct SLA.

Again, not a great fix, but it does indeed get the job done until your feature can become reality.

Thanks for the ideas Matt,

In the interests of sharing the way I have implemented part of what i'm looking for is by creating SLA's in relation to job role, customer facing tightest, execs and heads of middle ground and everyone else default.

Then in a similar way to you have mentioned utilised the department section, the difference being we use departments for reporting. Luckily FreshService allows you to have a requester in more than one department, so along with the departments pulled in from Active Directory I manually created 2 more, z.sla_custfacing, z.sla_execnman the (z. to put them at the end of the drop down. I then went through and added the relevant requesters to the relevant SLA group, this has allowed me to have different SLA's for job role ( some users in the same department may not be directly customer facing was the need before anyone asks).

Again inelegant but works for what I need currently on that front, for service requests all of the items have a mandatory due date as opposed to an SLA on the request type and we then set that as the due date as part of our process and workflow.

NB. The original request was from before the service catalogue integration, but I still think it would be better to have opening up more types to associate to an SLA in the roadmap for the future.