Hello, 

Not sure you wrote Not when you meant you know. 

For requester you need to use requester groups, Create & Manage Requester Groups : Freshservice
They can be dynamic depending of meta data on the requester. Makes it even mor imported that you import title and location of the requester. 

For agents you need to use agent groups but they are not dynamic so it will be overhead administration. You could create a new group only for the purpurs  of access. Then with a business rule you hide that group so no one can assign tickets to that group. It’s a bit complex but you can get it to work. 

You add the groups here

Thanks for the response @daniel.soderlund 

I know that I can do those things already but I do not think that it is a viable solution for our organization. It will be hard to manage and administer this over time as those Agent groups will need to be managed manually as soon as new Agents are added or when Agents are changing organizations etc.

I’m putting in an idea for this.

Dynamic agent groups would be nice as well. So you could control the access in AD 

I have the following scenario.

There is a requester group “Coordinator”.

This group can access the item e.g. “Rent a Car ”.

Some coordinators are agents too, so they cannot access this item because they are not a requesters.

This item is only available for Logistic workspace agents. We have coordinators from many departments.

Now there is a gap from coordinators without access this item. I don’t want to add these item in IT workspace (e.g. for IT coordinators) because all IT agents will see this item.

Why an agent could not be a requester ?

Requester is not an agent (ok), but I think an agent must be a requester too.

Yes, it’s limitation in the system. 

The solution I have used is to create a Agent groups called they Coordinator, Manager etc. 
Added the agents as observers. Then added the groups to the service items. It’s not as good as having dynamic groups as you can have for sequesters. 

Created a business rule that hides the groups from the group drop down list for everyone. 

//Daniel 

Hello Daniel,

Thank you.

We have a similar issue here. 

We have multiple workspaces with IT as the primary. 

If we set a Service Item to be visible to IT Agents and All Requestors, that Service Item will not be visible for other Business Agents unless we explicitly add them as an IT Agent or change the Agent visibility to All Agents

It makes no sense that by default a user within FreshService is not seen a a requestor unless they have explicit Agent access to a Service Item. 

Is there any solution to this or feature request open? 

You have this options and should be able to mix groups between different workspaces or select the whole workspaces. 

And Business agents can be member of the IT workspace, they get a view only access to tickets  in group that have access to. 

We have a similar issue here. 

We have multiple workspaces with IT as the primary. 

If we set a Service Item to be visible to IT Agents and All Requestors, that Service Item will not be visible for other Business Agents unless we explicitly add them as an IT Agent or change the Agent visibility to All Agents

It makes no sense that by default a user within FreshService is not seen a a requestor unless they have explicit Agent access to a Service Item. 

Is there any solution to this or feature request open? 

You have this options and should be able to mix groups between different workspaces or select the whole workspaces. 

@Daniel Söderlund If we have ‘All Requestors’ have visibility, and all accounts are requestors then this should allow access irrespective of whether the same user is an agent in a different group to what has been set to have visibility. 

Another non-answer from Daniel that is not a solution, completly conflicting with how permissions are supposed to operate.  Another broken feature of workspaces due to poor design.

This means it is pointless to use any agent visibilty setting other than all agents, where their dashboard must now restrict visibility of tickets that are not part of their workspace.  This is the only way the agent can also have requester visibility to request support from those workspaces.

Thank you. I’m not FW employee and I just tell of my own experiences and solution that I come up with. My livelihood is to help Freshworks customers and as they are also on the forum also  I  can’t just spill out all my solutions here,  I don’t get payed as I’m doing this is on my free time.  That's why I'm a little vague sometimes.

You are free to create a Idea or contact support. 

I agree that there are things that could been done in other ways with the workspaces. 

if you want all agents to have access then you set all agents, if you want just some agent groups from different workspacies you add them.

 

Looks like the idea was added a year ago already by the same person right after they started this thread.

Hello, 

Not sure you wrote Not when you meant you know. 

For requester you need to use requester groups, Create & Manage Requester Groups : Freshservice
They can be dynamic depending of meta data on the requester. Makes it even mor imported that you import title and location of the requester. 

For agents you need to use agent groups but they are not dynamic so it will be overhead administration. You could create a new group only for the purpurs  of access. Then with a business rule you hide that group so no one can assign tickets to that group. It’s a bit complex but you can get it to work. 

You add the groups here

 

Thank you for the clarification! I see now that requester groups are the way to go, especially with the ability to make them dynamic based on metadata. I'll ensure to import the title and location of the requester as you suggested. As for agents, I understand the challenge with managing static agent groups. Your suggestion to create a group specifically for access purposes and then hide it with a business rule sounds like a workable solution, even if it's a bit complex. I appreciate the guidance—I'll give this approach a try!