This page provides organizations with a guide to the setup and structuring of AMP to ensure a successful deployment and utilization of AMP throughout your organization. This guide covers the common application of AMP's structures and permissions model to real world organizations. It is important to note that this information is meant to be a guide rather than a concrete instruction. Level Access will provide expert guidance that is specific to your organization during the official implementation phase of deploying AMP.
On this page:
AMP structures
This section defines the different structures that AMP has to offer, and a mapping to typical industry structures and groups. AMP provides for three main structures that will help to fit AMP into an organizations different lines of business, web property owners and testing groups. These structures are organizations, child organizations and asses.
Organization
An Organization is the root level structure within AMP. An organization represents a group of users. Organizations are sub-divided by assets (see below) which allow for the more granular assembly of information for each digital property managed within AMP.
The root AMP organization is always named after the company or organization name. For example Acme Corporation. In the case where the company or organization is smaller in size (perhaps only has one group of testers, or a small number of properties to be tested) a single organization can suffice. That single organization can then be further sub-divided by assets to organize all testing efforts and reports related to each digital property.
Child organization
For larger companies and organizations it is often the case where there are several lines of businesses or independent groups working under the parent company or organization. A great example of this is a large university comprised of several campuses. Each campus has its own web properties that must be tested. Each campus also has their own group of testers. In this case a child organization can be created for each campus to all them to operate independently, but still remain as a single entity per the root organization for the university.
In a similar situation a large company may be comprised of several different business units. These units operate independently, but are still part of the main companies accessibility initiative. In this case a child organization can be created for each line of business. This still allows the organization to designate a single role or a team of people who would be able to see compliance reporting from a top down perspective.
Assets
An asset in AMP can be thought of as a folder that groups reports and tests for a single asset owned by the organization. For example, an organization will typically create an asset for each site, or main section of a site, that is to be tested over a period of time. The idea here is that testing results over a period of time for a given property can be stored in a single asset. This not only provides for an easy way to find the information within AMP, but also provides for a roll-up compliance score for that resource over time.
Who has access to what?
AMP permissions work on a simple top down approach. Therefore, organization administrators can see down to any child organizations (from their own organization), but they can not see up to a parent organization. They can also not see laterally to a sibling organization. This is by design. The idea here is to keep the business unit or group focused on what is most relevant and important to them from a reporting standpoint. It is important to note that beyond the default set of permissions users can also be explicitly invited to view assets and reports outside of their organization.
More on AMP Asset and Report Permissions.
An Organization administrator at the root organization will have omniscient access to all organizations, assets and reports.
Matching AMP user types to your organization
For a complete breakdown of AMP user types please see the AMP User Types help page.
Typically root organization administrators are the key stakeholders in your accessibility initiative. These are the people who understand what accessibility standards apply to your organization, have the authority to make such decisions and have the proper knowledge needed to make any updates or changes to these types of settings. These are the users who also typically oversee the entire accessibility initiative, not just a part of it. Typical user roles include:
- Section 508 Coordinators
- Chief Information Officers
- Accessibility Program Directors
Organization Administrators are also typically designated at the child organization level. The model here is that for every child organization there is a designated "power user" for that group. This makes it easier for the root organization administrators to disseminate information to their user groups, gather information on what training is needed and assist in driving the overall accessibility initiative throughout the different areas of the organization. Common child organization administrators are:
- Product Managers
- Compliance Officers
- Campus Leads
- Development Leads
From there, organizations are comprised of those that will be performing testing (Standard Users) and those that simply want to view reports (Viewers). The standard users are typically those members of the organization that will actually be performing testing such as:
- Developers
- Quality Assurance
- Content Authors
- Designers