Client Portal
Multiple Client Portals
- Pros
- Uniquely branded landing pages for that entity, including logos, colors, introductory info, etc
- Portal access is handled at the user access level, so you need to rely less on group permissions to hide items (if needed)
- Cons
- Multiple places for client users to find KBs, services, general information, etc.
- Public service from multiple portals show up in the services look up page across all ticketing apps
- See the related KB for more info on that
- Scenarios/General Use
- For entities that have multiple campuses/locations/depts, each location is likely to get their own portal
Single Client Portal for all TDX groups
- Pros
- Single point of entry for all end users to find KBs, services, general information, etc
- Cons
- Relies heavily on group permissions to hide things from the appropriate user
- Scenarios/General Use
- Single group using TDX
- Multiple sub depts (such as IT, and then under IT, Desktop Support) sharing space with the parent dept
Ticketing
Multiple Ticketing Applications
- Pros
- Tickets are only visible to admins and users who explicitly are given access to the ticketing app
- Notification Templates can be branded to each organization
- Cons
- Multiple apps need configured individually, and ticketing app configuration cannot be copied/cloned
- Scenarios/General Use
- For entities that have multiple campuses/locations/depts where the work is completely different and worth segregating
- Please note, if groups share a ticketing app, ALL people inside of that app can see ALL tickets
Single Ticketing Application for all TDX groups
- Pros
- Automation rules will hit all of the tickets that come in from all catalogs, email monitors, and APIs, and therefore can more easily account for complex routing rules
- Do not need to configure more than 1 app, potentially decreasing the total cost of ownership
- Cons
- Users with access to the ticketing app can find at all times, any ticket located within that app, including sensitive tickets, or security related tickets
- Relies heavily on group permissions to suppress the creating of tickets using certain ticket types and/or certain forms
- Relies heavily on naming conventions since you need to keep track of which items are created for group A vs service Z, etc
- Scenarios/General Use
- Single group using TDX, such as IT
- Groups that collaborate very frequently, even though they may not be the same dept on the org chart are likely to share an app
Assets
Multiple Asset Applications
- Pros
- Can give granularity on how assets are stored and managed, which makes reporting easier
- Do not need to worry about reconciling the different asset import layers (such as vendor, product type, etc) with use cases from other groups
- Cons
- There are no shared asset settings like there are on the ticketing side (vis a vis, the shared ticketing settings), so sometimes configuration that you want in multiple apps has be added multiple times
- Scenarios/General Use
- Multiple depts need to track Assets in TDX, and that means those groups are likely to want their own asset app
Single Asset Application for all TDX groups
- Pros
- Only need to worry about configuring 1 asset app, and it's easier to keep reporting consistent when configuration is centralized
- Cons
- Will need to figure out how to blend or share the asset components to account for all of the different groups
- Scenarios/General Use
- Only 1 primary group wants to track assets inside of TDX (primary being defined as perhaps IT, and under IT, other groups like desktop support might end up importing some assets into the "IT" assets app)