WiscWeb allows faculty and staff to create and maintain websites that serve the campus mission. The websites are hosted within Amazon Web Services (AWS) and edited using WordPress technology. Styles and basic functionality are provided via the UW Theme, and additional functionality is provided via a select list of vetted plugins. Anyone with an active, valid NetID can edit a WiscWeb site.

For more information about the service, what is and is not offered, eligibility, and suggested use cases, please see the WiscWeb About page, the KnowledgeBase document on Eligibility, and the Terms of Service.

To check if a site is hosted by WiscWeb, please see the Sites Hosted with WiscWeb KnowledgeBase document. Additionally, WiscWeb sites will have the words “My WiscWeb Sites” in the top left corner of the dashboard.

The best sources for user training and troubleshooting are the Beginners Video Training Sessions and the KnowledgeBase hub.

Service Users

UW-Madison faculty and staff can request WiscWeb sites that serve the core mission of the University

Anyone with an active, valid NetID can edit a WiscWeb site

The service is not intended for personal sites, faculty profile sites, or student organization sites

Refer to: WiscWeb - Account eligibility and obtaining access

Availability

24x7

Server Information

Hosted by Amazon Web Services

Unique Support Conditions

• Users without NetIDs cannot edit sites. Groups seeking to allow 3rd party contractors to edit/access their sites must create Manifest Identities for them. WiscWeb does not create Manifest Identities on behalf of individual groups. 
• WiscWeb is currently not funded to support personal websites for faculty. More information about alternative options can be found here: WiscWeb - Options for faculty profiles.
• Refer to Sites Hosted with WiscWeb KnowledgeBase document to confirm that a site is hosted and supported by WiscWeb.
• If you're unsure, use Help Desk - Determining Where a Website is Hosted.

Select an appropriate service, category and subcategory from the options below.

• WiscWeb

• WiscWeb

• Bug Reporting - Use for bugs related to WordPress, the UW Theme, or approved plugins.

• Design Request - Requests related to the design of a website including a new logo, color change, font change, and any other stylistic embellishments.

• Errors and Alerts - Use for specific error or alert messages encountered while navigating a site. e.g. HTTP errors, flags in WordPress, form array/forms not sen

• Functionality Request - Requests for new features, technology, or functionality to be added to a website.

• General Troubleshooting

• Outage and Performance - Incident related to slowness or a site outage.

• Permissions and Access - Account creation, site and user permissions, manifest group inquiries.

• Plugins - Use for issues, concerns, or questions relating to WiscWeb's approved plugins or requests for new plugins.

• Site Launch - Requests related to the launch or a go-live of a website, including redirect questions, hosting questions, how the process works, rescheduling.

• Training or How-to - Requests relating to in-person or online training, new training dates, instructional inquiries, and 'how-to' documentation.

For ALL incidents, gather the following minimum required information:

• Clear, detailed description of the problem
• Complete customer contact information

Copy/paste the following additional required information into the WiscIT Description field:

Click the text box to select all, copy with Ctrl+C.

Example Case:

• NetID: bbadger
• Site URL: buckybadger.wisc.edu

Before escalating, please confirm the site is actually hosted by WiscWeb: WiscWeb - Full WiscWeb website list. If the website is not on that list, refer to: Help Desk - Determining Where a Website is Hosted.

For a visual depiction of this workflow, see the following image: Process Diagram

1. The Help Desk receives one or more customer contacts for an issue that is identified as a potential outage.

2. HDQA checks the outages page for any related open planned outages. HDQA then chats SNCC via Service Support Chat Room and confirms an outage should be declared.

3. If an outage is identified, SNCC should immediately begin creating an Outage.

4. HDQA receives the Incident from the agent(s) who handled the initial contact(s).

5. HDQA creates a problem in Cherwell by selecting New > Problem. HDQA then fills out the fields in the Identify and Classify section of the Problem with the information they gathered from the Incident(s). For assistance with Problem creation, reference: Help Desk Training - Create a Problem in WiscIT without the Problem Manager or Help Desk Training - Create a Problem in WiscIT with the Problem Manager.

   

6. When the Problem has been created and saved, HDQA clicks the team name in the Owned by pane and assigns the Problem to 'SNCC-Sysops' or 'SNCC-Network' as directed by the service handling doc or SNCC staff.

   

7. SNCC receives the Problem and links the Problem to the Outage from the Problem screen.

8. HDQA links the original Incident(s) and any additional relevant Incidents they have received to the Problem. For instructions on performing this step, see WiscIT - Linking an Incident to a Problem.

9. As calls continue to come in, Help Desk agents should link the Incidents to the Problem themselves. Level 1 agents should simply save the Incident at this stage; do NOT resolve these Incidents or escalate them to HDQA.

10. When the outage is resolved, SNCC will go into the open Problem and select the Resolve Attached Incidents link on left side of screen; this will email all customers that their Incidents should be resolved. The email will direct customers to contact the Help Desk if they believe the issue is still occurring.

    

11. If the problem needs follow-up investigation, SNCC will assign the Problem to the appropriate team.

• If an outage occurs after work hours, please first check to make sure it is a WiscWeb site. If so, follow normal outage process.