This is a very solid question and one that I wish we had asked ahead of our engagement on a project to migrate to the RF environment... below is an insight to some of the issues and limitations we have experienced.
1. It is not possible to associate multiple contacts to an incident... imagine a line manager needing to be involved in a call with one of their team... you can no associate them to the incident and there is no way to track their interaction with the incident.
2. The online portal that is described a fully brand able environment is not 'full brand able' RF create URL links back to them all over the place, if the user log in fails it goes off to a Sales Force platform and confuses the viewer no end... in addition there is a strap line at the bottom of every page with BMC and RF Copyright notice.
3. For us we needed to be able to share service desk access to internal resources within a company, eg the head of IT.. They require full visibility across the platform, the only way to do this is to purchase a licence which is then dedicated to them.
I reckon that we will be able to fine tune the platform to effectively support a multi tenanted environment... although this is not an out the box solution and does require a significant investment in pro services and your own development time.
A few solutions:
First you can optionaly work with a customer portal and you can specify what client will see, so also reports on top of all the incident/Request functionality! Contact your sales agent for this.
Best scenario for Remedyforce is to use "data segregation". When you segregate users, only users who belong to a department of the role hierarchy are available when you create or assign records.
You have the following departments or companies:
For example, if you implement user segregation, staff members and System Administrators in the HR (role) department of the role hierarchy can create incidents for the clients of the HR department. Staff members and System Administrators cannot create incidents for the clients in the IT or facility departments. When staff members and System Administrators in the HR department select a client, only the related clients of the HR department, contacts for the HR department and all system admins will become visible. So, that might work for you!
Below the answers on your issues:
1. We can create a seperate field for "Line Manager" this can be a lookup to users, or in standard SFDC layout a filtered lookup, with filter "Manager". That way you can also report on this.
2. In the Customer portal settings you can enter/specify your login URL. The URL's behind the logo's are not changeble!
3. This can be arranged with permissions and profile changes, but require additional work.
Let me know if you would need our help!
Paul Donders "InfraVision"
I have just asked the same question related to one MSP they are asking if they can leverage RF to support their customers in a multi-tentant environment, with intensive contract management, SLAs, inventory/spare parts management ... I understand RF is limited and not very suitable ...
Hope someone can complement this post or answer to my recent thread,
Yes this can be done based on sharing rules and role hierarchie.
It needs customization, and sharing rule for each related object. This all takes time and need be worked out carefully so you don't make mistakes, combined with a decent test period.
We did this for one of our customers.
Based on your contract question, please consider the std sfdc contract object what can be linked to for example incidents!
Is this possible in Remedyforce OOTB?
Create several users that are assigned to the Service desk staff profile and limit to what they can see in the remedy force console?
for Example User A is working on Account/Company A
User B is working on Account/Company B
and user A can not see any tickets for company B etc.
Yes, this can be done.
First you can create different console layout based on different profiles.
By default people/users see only tickets that are assigned to them, or where they are a member of a certain queue.
On top, based on account create an assignement workflowrule, or routing engine to assign the ticket to the correct queue.
By now we did this for many customers that support different accounts, but also for different departments like HR, Finance, Facility etc.
So there are many options and possibilities, but be aware that you need to know what you are doing, specially when for example security related data as HR processes come into play!