Overview
This consultation process is designed to:
- Provide expert advice to campus partners seeking web solutions
- Ensure proposed solutions are appropriate and not duplicative of existing campus resources
- Guide partners through the decision-making process for web application development and hosting
- Facilitate informed vendor selection when external solutions are needed
- Ensure compliance with university requirements, including security, accessibility, branding, etc.
- Assist with the contract negotiations to ensure applications have ongoing support
Target Audience
The following groups should be aware of this consultation process and refer others to it:
- UO Communicators - Marketing and communications professionals
- Chiefs of Staff - Department leadership
- IT Professionals - Technical staff in departments
- Drupal Community Members
- Web Community of Practice (Contact: Rachael Nelson)
Consultation Workflow Summary
Here is our team's entire workflow from beginning to end. For more information, please consult the additional content below.
- Initial Request Intake (TDX)
- Consultation Meeting with IS Consultant
- Gather requirements
- Assess complexity
- Evaluate budget
- Evaluate Campus Solutions
- Can existing tools meet the need?
- If YES → Refer to campus service
- Provide setup guidance
- Follow up on implementation
- If NO → Continue evaluation
- Determine if UO Communications Appropriate
- Marketing/branding focus?
- No complex workflows or web forms needed?
- If YES → Refer to UO Communications
- If NO → Continue evaluation
- Determine if Information Services Appropriate
- Need custom workflows or online forms?
- Enterprise-level application?
- Complex integrations with UO systems?
- If YES → Refer to Information Services
- Custom web application development
- Enterprise solutions
- If NO → Continue to vendor guidance
- Vendor Guidance
- Assess Vendor list for best fit for client
- Share approved vendor list
- Provide contracting requirements
- Review security/SSO/accessibility needs
- Document and Log Request (JIRA)
- Record in tracking system
- Note decision and rationale
- Track outcomes for future analysis
Initial Request Submission
Use the Web Development and Hosting Support in TDX to submit your consultation request.
Create initial ticket and choose the appropriate request type:
Required Information:
- URL: Full website address
- Problem Description: What isn't working as expected?
- Steps to Recreate: How can we reproduce the issue?
- Impact: Who is affected and how urgently does this need resolution?
- Access Information: Do you have admin access? What level?
Phase 1: Requirements Discovery
Select the title of each accordion panel in order to see its contents.
Primary Purpose:
- What is the main goal of this website/application?
- What specific problems does it solve?
- What would success look like?
Content and Functionality:
- What type of content will be published? (Static pages, blogs, forms, databases, media, video)
- Will visitors need to create accounts or log in for site functionality?
- Will you collect any user data? What types?
- Do you need e-commerce or payment processing?
- Will you need integration with other UO systems? (SSO, Banner, Canvas, etc.)
Audience and Scale:
- Who is the primary audience? (Students, Faculty, Staff, Alumni, General Public)
- How many users do you anticipate? (Daily/Monthly)
- What types of users will access the service and approximately how many of each type?
- Is this for a specific department, college, or university-wide?
Complexity Assessment:
- Is this primarily informational (brochure-ware) or interactive (applications, forms, databases)?
- Do you need custom functionality or standard CMS features?
- Will you need APIs or data integrations from other existing data sources?
- Do you have specific technology requirements or preferences?
- Will payment or e-commerce occur on the site?
Performance and Availability:
- Do you anticipate traffic spikes? (Registration periods, events, etc.)
- What are your performance expectations? (Page load times, etc.)
- Is this application mission critical to campus functionality? What will be the effect if the application is unavailable for a period of time?
Data Management:
- What data will be collected by the service?
- Does this involve sensitive data? (FERPA, PII, Health Information, etc.)
- Any data retention requirements? How long does data need to be retained?
- Who owns the data and content?
Ongoing Management:
- What UO Employment position will be the site steward?
- This person will sign the web attestation acknowledging responsibility for ensuring the site meets legal, brand and ongoing maintenance requirements.
- Who will maintain content? Do they have technical skills?
- How frequently will content be updated?
- Who will handle technical maintenance and updates?
- Do you have staff allocated for this, or need training?
Long-term Viability:
- What is the expected lifespan of this site? (1 year, 5 years, indefinite)
- Do you have an ongoing budget for hosting and maintenance?
- What happens if the key staff leave? Is there a succession plan?
Financial Planning:
- What is your total project budget?
- Have you allocated budget for:
- Initial development
- Annual hosting costs
- Ongoing maintenance
- Accessibility compliance
- Security updates
- Do you have a funding source identified? (Department, grant, auxiliary)
Timeline:
- When do you need this to launch?
- Are there specific deadlines or event dates?
- Is the timeline flexible or fixed?
Phase 2: Existing Solutions Assessment
Before recommending external vendors, evaluate whether existing campus solutions can meet the need:
Content Management and Blogs:
- UO Blogs (WordPress) - For blogs, simple sites, and departmental pages
- Self-service, UO branded, accessible templates
- SSO integrated, no cost to departments
- Best for: Simple sites, news, event listings, simple portfolios
- UO Drupal Hosting - For complex departmental and college websites
- Professional web services support
- Custom functionality possible
- Best for: Multi-section sites, complex content types, integrations
- SharePoint / Microsoft 365 - For internal collaboration and document management plus intranet sites
- Built-in SSO, file storage, team collaboration
- Best for: Internal departmental sites, project collaboration, document repositories
- Pages - For simple, static informational pages
- Quick setup, minimal technical requirements
- Best for: Single-page sites, landing pages, quick info sharing
Forms and Workflows:
- TDX (TeamDynamix) - For ticketing, service requests, and workflow automation
- Form builder, approval workflows, reporting
- Best for: Service requests, IT support, process automation
- OnBase - For document management and workflow
- Enterprise document management, records retention
- Best for: Official records, complex approval workflows
- Microsoft Forms / Power Apps - For surveys and simple data collection
- SSO integrated, export to Excel/OneDrive
- Best for: Surveys, registration forms, simple data collection
- Forms.uoregon.edu
- Approval process workflows
- Digital Signatures
- Adobe Sign
- Approval process workflows
- Digital Signatures
Other Campus Services:
- Information Services - Custom Web Application Development - For enterprise-level websites and applications
- Check with IS for existing APIs or data services
- Check with your college/division/department for existing web properties
- Business Affairs for e-commerce and payment processing.
Phase 3: Decision and Recommendation
Based on the consultation, determine the appropriate path:
Outcome: Refer to appropriate campus service
- Provide contact information and setup instructions
- Offer training resources if needed
- Follow up to ensure successful implementation
When to refer:
- Site does not have specific grant funded branding requirements
- Site purpose has a relation to existing web properties (go where the audience already is)
Action: Connect with the existing web property site steward for consultation
When to refer:
- Need for custom workflows or online form development
- Enterprise-level applications
- Complex integrations with UO systems (Banner, Canvas, etc.)
- Custom business process automation
- Advanced data management and reporting needs
- Campus solutions exist but don't meet complexity requirements
Action: Connect with Information Services Web Application Development team for consultation
When external vendors are appropriate:
- Campus solutions cannot meet specific technical requirements
- Need for specialized functionality not available on campus
- Grant or external funding requires specific technology or branding requirements
- Unique compliance or regulatory requirements
Phase 4: Vendor Selection Guidance
If external vendors are recommended, provide the following information:
Approved Vendor List
IS Staff Provide Recommended Vendor(s):
- Assess best fit for
- Price points
- Technology stack
- Technical requirements
UO Approved Vendors (via RFP):
- Access the PCS Portal
- From the Home tab, select Query Submitted Matters
- In the search field paste: 432000-01073-RFP and press Enter.
- This should return a list of about eight approved vendors.
- Contact: Tina Davidson (PCS)
- These vendors have already been vetted by the university.
Required Contract Elements
When working with external vendors, ensure the following are included in contracts:
Vendor must provide:
- Current compliance documentation demonstrating recognized security standards:
- ISO 27001, or
- SOC 2 Type 2, or
- HECVAT (Higher Education Community Vendor Assessment Tool, version 4.0 preferred)
Vendor must agree to:
During contracting, ISO will request:
- Types of data the service will collect
- Types and approximate number of users
- Integration requirements with existing UO systems
- Security documentation (HECVAT, SOC 2 Type 2, or ISO 27001)
Contacts:
- Leland VanBrunt (ISO)
- Andy Preising (ISO)
Preferred: Entra ID (Microsoft Azure Active Directory)
- Benefits: Cloud-based resilience, broad support, access control integration
- Protocols: SAML or OAuth 2.0/OpenID Connect
Also Supported: Shibboleth SSO
- Protocols: SAML 2.0 or CAS
- Note: UO is transitioning away from Shibboleth
Vendor Requirements:
Vendors must specify which authentication protocols they support:
- SAML 2.0 or CAS only → University supports via Shibboleth IdP
- SAML or OAuth 2.0/OpenID Connect → University supports via Entra ID IdP (preferred)
- Both protocols supported → Entra ID preferred
Vendors should propose the authentication method they most commonly support for optimal implementation and sustainability.
Contact:
Legal Requirement: All university web properties must comply with:
- WCAG 2.1 Level AA (Web Content Accessibility Guidelines)
- Section 508 of the Rehabilitation Act
- ADA Title II (Americans with Disabilities Act)
Vendor must provide:
- Accessibility compliance documentation
- VPAT (Voluntary Product Accessibility Template) if available
- Commitment to maintain accessibility through updates
- Support for accessibility testing and remediation
Required in contract:
- Explicit accessibility compliance terms
- Vendor responsibility for accessible code/platform
- Client ability to create accessible content
- Remediation process for accessibility issues
- Regular accessibility audits
Resources:
Contact:
Hosting and Infrastructure:
- Uptime guarantees (typically 99.9% or higher)
- Backup frequency and retention policy
- Disaster recovery procedures
- Server/platform maintenance windows
Software Updates:
- Security patch timelines
- Platform/CMS version updates
- Plugin/module maintenance
- Third-party integration updates
Support Terms:
- Support hours and response times
- Contact methods (phone, email, ticket system)
- Escalation procedures
- Service Level Agreements (SLAs)
Content Ownership:
- UO retains ownership of all content and data
- Data export capabilities and formats
- Migration support if contract ends
- Content backup and archival procedures
Recommended Terms:
- Initial contract period (typically one to three years)
- Renewal options and terms
- Price lock or escalation limits
- Termination clauses and notice periods
- Data return/deletion procedures upon termination
Ensure clarity on:
- Initial setup/development costs
- Recurring hosting/maintenance fees (monthly/annual)
- Per-user or tiered pricing structure
- Costs for additional features or modules
- Bandwidth/storage limits and overage costs
- Support costs (included vs. additional)
- Training costs
- Price increases and escalation caps
Any site served from a uoregon.edu domain has to abide by brand standards. If the site has branding in grant requirements then it needs to use UO Minimal Branding standards *TBD
Tracking, metrics, and resources
Select the title of each accordion panel in order to see its contents.
Log all consultations to:
- Understand demand patterns
- Identify gaps in campus services
- Inform future platform investments
- Demonstrate value of consultation service
- Track outcomes and success rates
Track:
- Request date and requester
- Department/division
- Problem type
- Solution recommended
- Campus service vs. external vendor
- Budget range
- Outcome status
Additional Resources
Campus Contacts:
- Web Community of Practice: Tony Herrig
- University Communications: Jason Huebsch
- Information Security Office (ISO): Leland VanBrunt, Andy Preising
- SSO/Identity Management: Chris Bernard
- Procurement and Contracting Services (PCS): Tina Davidson
- IS Web Application Development: Jesse Sedwick
- API Gateway and Access: Keith Folsom
- Accessibility: Grey Pierce
Documentation:
Notes for IS Consultants
Select the title of each accordion panel in order to see its contents.
Start with Why? - understand the underlying need, not just the requested solution
- Look for existing campus solutions first - they're often more sustainable
- Consider Information Services for custom enterprise solutions before recommending external vendors
- Evaluate if custom workflows, online forms, or complex integrations indicate need for Information Services
- Consider total cost of ownership, not just initial costs
- Assess long-term sustainability - who will maintain this in two to three years?
- Ensure compliance is addressed upfront, not as an afterthought
- Document decisions and rationale for future reference
- No identified budget or funding source
- No staff assigned for ongoing maintenance
- Unclear purpose or success criteria
- Duplicates existing campus functionality
- Unrealistic timeline expectations
- Doesn't consider accessibility or security requirements
- Check in 30 days after recommendation
- Track implementation success
- Gather feedback for process improvement
- Update documentation based on lessons learned
Need help?
For more information, see (service offering page) or select Create a Ticket or Request Help from this page.