FIG. 2 is a block diagram illustrating a conventional architecture 200 for enabling a technician or customer service representative of a multi-tenant service provider to access a tenant's account on Mufti-Tenant SaaS Application Platform 210. FIG. 2 illustrates aspects of an example mufti-tenant architecture that includes the use of credentials for purposes of authenticating each user desiring access to a tenant's account. As shown in the figure, a set of user credentials 222 are stored and referred to by an authentication process 226 to permit service representatives of the platform operator to obtain access to the accounts of individual tenants (shown as “Internal Support Access to Tenants” 220) via Service UI 218. Each tenant may have access to one or more applications, which may be provided by the mufti-tenant platform, typically (although not required) in a Mufti-Tenant Software-as-a-Service (SaaS) application mod& 210 and typically has a separate Tenant Data Store 212A, 212B and 212n. The tenant's users (employees and/or customers) 202 may access the data 212A, 212B and 212n and applications resident on platform 210 remotely through Tenant User Interface 217A, 217B and 217n using a suitable client device and communications network. Data used in service and support may be maintained in Service Store 225.