Hi All, I'm curious how folks are handling the different scenarios where an MSP is creating tickets for a client and being able to track the original requester. Speaking in a domain-separated environment. Apologies in advance if this is confusing as I'm still wrapping my head around parts of it. Let's say MSP provides an application hosted in MSP environment, to client A. If the client is requesting something related to this service, a Service Request could be created under 'Client A' and the 'Requested For' can be a user in Client A's Company. What if the request is indirectly for the client? Maybe it's the MSP application team (tier 2) that needs to request a patch on the OS. It's still related to Client A but the 'Requested For' really wouldn't make sense as a client user. What company and requested_for are used in this (or other) scenarios? Ok, let me pause there before I confuse things more. Hopefully starting a conversation... ... View more

Hiya,   I work for an MSP who offers and support infrastructure services to customers, our customers are onboarded to our platform as part of domain separation and our domain model is defined.  I am trying to wrap my head around the CSDM service structure for services in this way.    As an example an Infrastructure Service. Traditionally you would create a business service called Infrastructure Management and have Service Offerings called Standard, Gold ect.... As part of CSDM that Offering would be related to an Application Service for say the data centre. This would then have CI's for all the servers as part of that data centre.   For an MSP this doesn't work due to not having the visibility per customer.   I have been trying to design a few models 1. Business Service - Infrastructure Management, Service Offering - Customer X Infrastructure Management, Application Service - Customer X Data Centre 2. Business Service - Customer X Infrastructure Management, Service Offering's - Maintenance/Access/Software, Application Service - Customer X Data Centre Any advice would be appreciated and if there is any reference material for this out there to read would be helpful. ... View more

I am a contract change manager for a major metropolitan client. I am the one who is responsible for preparing each week's change requests for CAB review. I often find typos, punctuation errors, sentences that don't make sense, incomplete information, etc., and make corrections on behalf of the Requesters/Implementers. The company I represent has a change manager who always has the final say and says I should NOT do any of this but rather, send it back to the Requester/Implementer. I never add or remove content . . just corrections that allow the change to make sense. I asked if it would be OK if I received permission from a Requester/Implementer, in writing, to make updates and he said no. Am I violating any known best practice by performing some basic editing and/or updates? By sending changes back to NEW everytime I see small errors that I can easily correct really slows the approval process down and makes my job alot harder. Thoughts? ... View more

The platform UI works correctly when ‘Toggle Domain’ is used to change the query criteria from the current record domain to the current user domain.  Only in the SOW workspace UI does the ‘Toggle Domain’ capability NOT work correctly. We had the same issue in CSM/FSM Workspace after Vancouver Patch 9.2.   It seems more than a bit perplexing that the product’s 2 UI methods do not work in the same manner for this very important capability for an MSP company. Our tier 2/3 business area has adopted the SOW workspace as their primary user interface and NOT fixing this issue will greatly affect our ability to deliver service.  Use of the workspace UI makes our agents more efficient and effective and they can deliver results to our customers in a more timely manner.  Discontinuing the use of the workspace UI will directly affect their ability to work quickly and efficiently and, of course, re-training will be required.  This will definitely cost us time and money not to mention serious negative changes in customer satisfaction.   Product Team has stated that the issue will be addressed in Yokohama which deems SOW Workspace useless for an MSP with domain separation. And, the family upgrade isn't available until March. Absolutely no support from the account or product team. If this fix is in Yokohama then why not backport the fix in the next Xanadu patch? As it stands, SOW will remain unusable for us for almost half a year. Unacceptable. Anyone else experiencing this issue? What's your workaround, if any?   Thanks, LC ... View more

Hello, We're an MSP and have a domain separated instance and had questions around supporting other MSP providers in our instance. We're looking for best practices around loading foundation data (location, contacts) for our client's (MSP) clients.   Should we add our client's ABC Company (MSP) clients contacts under ABC Company and differentiate them by Department or Location?   Should we build our client's clients under their own 'Account/Company'?   We could run into an issue where we sell services to our client's clients and they become our client. So if we build these contacts under our client (MSP) then they wouldn't be able to exist under a 2nd Accounts/Companies (their company). ... View more