6/25: Allvue User Access Training 1
Technical Troubleshooting and Initial Coordination
The session begins with the presenter (Lisa) experiencing technical difficulties with the Microsoft Teams application.
Interaction regarding system access involves an error code:
<Error>AccessDenied<Message>Access Denied</Message><RequestId>SJ44B6WNPEMF9XYF</RequestId><HostId>hzMqA5gFjDXY2SWnXaTjkpa8PCNdqqthr+MhqlXPTDbtLvWiqar0a2drjgsNZ05F744SSyPWYLQ=</HostId></Error>.Luke and Lisa discuss system login issues where a new password and captcha are required, yet access remains denied. This is attributed to Recent changes made by Afiya regarding user access.
Gus is tasked with recording the session and taking minutes to capture the "information overload."
Overview of AllView Ticket Processing
The training focuses on processing AllView tickets for clients on the standard database, specifically excluding co-sourcing databases for this session.
**Identification of Tickets:** The target tickets are labeled "AllView Standish," indicating they belong to the standard database rather than co-sourcing.
**Key Information Needed from Tickets:**
User Email: The address of the person being added.
User Position: Less critical for AllView compared to ARC, where roles like "Associate Manager" are assigned.
Client: The specific entity the user is being added to (e.g., Homestead Capital).
Investor Portal Link: If the ticket says "," the client does not have one.
Client Hub URL: The link to the specific client management hub.
Reporting Portal: For Standish clients, this is generally the universal Standish reporting portal URL.
**Discrepancies:** If URLs are missing or labeled "TBD" (to be determined), investigation is required before processing. Practitioners must check Smartsheet for updates and consult reviewers.
Fund Accounting (NAV) Status Verification
The first system step is to log into NAV (Fund Accounting) and verify the user's current status.
**Navigation:** Use the top-right search function to find "Users" and "User Setup."
**Users Page (Status Check):**
This page confirms if a user is "Enabled" or "Disabled."
For existing users (e.g., Preeti), if they are enabled, practitioners proceed to access assignment.
For non-existing users, a Jira ticket must be submitted to AllView to create the account before proceeding with permissioning.
**User Setup Page (Code Assignment):**
This is where specific client codes are assigned to users to enable posting capabilities.
Identifying Detail: The User ID is the portion of the string following the slash (e.g., + last name).
Field: "Access to client companies."
Process: Click "Client Access," search for the client (e.g., Homestead Capital), select the code, and click "OK."
**Technical Context:** Adding a client code permissions everyone assigned to that code to the specific funds. This step causes the system to process for several minutes, often displaying a "not responding" status due to the volume of data being synced.
CRM Configuration and Team Management
Practitioners must manage the user and team records within the CRM to ensure synchronized access.
**Searching Users in CRM:**
Navigation: Settings $\rightarrow$ Security $\rightarrow$ Users.
Verification: Ensure the username, full name, and email match the ticket and NAV entry.
**Assigning Users to Teams:**
Teams are used to grant access grouped by client engagement.
If a team (e.g., Homestead Capital) does not exist, it must be created manually.
**Creating a New Team in CRM:**
Navigation: Settings $\rightarrow$ Security $\rightarrow$ Teams $\rightarrow$ New.
Team Name: Use the full client name (e.g., Homestead Capital).
Business Unit: Set to "Standish Management."
Administrator: The person setting it up (though all have full admin access).
**Assigning Security Roles to Teams:**
Two specific roles must be added via "Manage Roles":
Verify against an existing team (like Diverseus Capital) to ensure the correct roles are selected.
**User Liaison:** Users can be added to teams via the User Card or the Team Card; both methods achieve the same record linkage.
Creating CRM Contact Cards for Extranet Permissions
Contact cards are mandatory for managing extranet permissions and are unique to each client the user serves.
**Navigation:** Settings $\rightarrow$ Investor Relations $\rightarrow$ Contacts.
**Fields for New Contact Creation:**
First and Last Name: Copied exactly from the ticket or NAV to maintain unison.
Firm: Use the magnifying glass to select "Standish User."
Email: Must be filled even without an asterisk requirement.
Client: select the specific client (e.g., Homestead Capital).
Investor Portal ID: This is the user ID portion after the slash in NAV (e.g., the user's username).
**Administration Settings:**
Owner: The default must be changed to "Standish Management service account" to keep data uniform.
Configuring Client Extranet Permissions
After creating the contact card, the user must be granted specific extranet rights within the client profile.
**Navigation:** Settings $\rightarrow$ Clients $\rightarrow$ [Select Client Name].
**Process:**
Select the arrow next to the client name in the top ribbon.
Navigate to "Client Extranet Permissions."
Click "Add new client extranet permission."
Search the specific Contact Card (linked to that client) and save.
**Documentation:** Take a screenshot showing the user's name next to the client extranet entry for the ticket reviewer.
SOC Audit Compliance and User List Maintenance
All user additions must be logged in the "All View User List " located in the shared drive:
Standish management/Client Solutions/Users.This document is required for the SOC audit conducted by Chris (reviewer).
**Data Entry:**
Activation Date: Use the current date (e.g., ).
Status: Mark the user as "Basic" and "Enabled."
Note: If a user was previously disabled, re-enable the existing row rather than creating a duplicate, ensuring the username remains unique.
Jira User Access Request Submission
Once internal systems are prepped, a formal request is sent to AllView via their Jira Customer Support Portal.
**Request Details:**
Request Type: Creation or Modification.
Action Type: Individual (or Bulk, which is limited to users per request).
**Product Selection (The "Standard Five"):**
Client Hub: Role = "Portal Admin"; Additional Access = "Cube."
CRM: Role = "Standish engagement team"; URL =
stanagemanagement.crm.alterreturn; Outbound emails = Yes.Fund Accounting (NAV): Role = "Basic fund accounting roles"; URL = the specific FA portal link.
Investor Portal: Roles = "Admin," "Configurator," "Reviewer," and "Impersonation."
Reporting Portal: Role = "Member"; Additional Access = "Excel cube," "Power BI (Read-only)," "SSRS report generator."
**Sharing Permissions:** Ensure the ticket is shared with Luke, Chris (reviewer), and John Domingo (approving manager) so they can track progress.
**Welcome Email Redirection:** Set the "Welcome Email" to be sent to "Onboarding" rather than the user. This allows SysOps to modify the email text before the final delivery.
Communication and Verification Workflow
**Review Process:** Flip the Zendesk ticket status to "FC Review Required" so Chris can audit the steps.
**The Modified Welcome Email:**
Practitioners must remove references to AllView Support to prevent users from contacting external vendors directly.
Redirect the user to submit a ticket to SysOps for any problems.
Include a link for "password reset with impersonation instructions."
**Distribution List:** The finalized email should be sent to the user and CC'd to the manager (John), Luke, Alec, Chris, and the onboarding assistant (Gus).
Questions & Discussion
**Old vs. New Methods:** Luke and Lisa discuss the transition from using manual Excel spreadsheets for user access (which required emailing files to AllView) to the current streamlined Jira portal. The old process lacked a robust review stage and required saving confirmation files in local folders.
**Handling New vs. Returning Users:** Luke emphasizes checking for former accounts (e.g., users who took maternity leave) to prevent duplicate usernames and emails. The email serves as the primary unique identifier for logging into the Reporting Portal, CRM, and NAV.
**User Inquiries/Pings:** Staffing and interns often ping practitioners privately for access updates. Luke advises redirecting all such inquiries to the staffing department or the SysOps ticket system to maintain process integrity and avoid personal interruptions.
**SysOps Email Identity:** There is a proposal to send the final welcome email from the "SysOps" alias rather than personal accounts to prevent users from replying directly to practitioners. This would force users into the automated ticket system, though testing is required to ensure responses are not blocked by Zendesk preventions.