FAQs

Yes. The platform is not limited to Drupal or Quick Start websites. It can crawl publicly accessible sites built with most content management systems and web technologies, provided the pages are reachable by a standard crawler and are not restricted by authentication, robots.txt, or other access controls.

The website crawler does not authenticate to access protected content. For content behind a login or within a third-party system, the available APIs or integration methods may need to be evaluated to determine whether a custom data pipeline can import the content into the knowledge base.

Content generated only after client-side JavaScript runs may not be extracted. This commonly affects some single-page applications. Content included in the initial HTML response can be crawled.

The crawler follows reachable pages whose URLs begin with the configured primary base URL, except for pages or paths that are excluded. A page must be discoverable and accessible through the website structure. Individual pages do not need to be listed separately.

Yes. Publicly accessible external websites can be configured as primary or additional sources. Linking to an external website from a crawled page does not cause the entire external website to be crawled; it must be added separately.

If https://research.arizona.edu is listed as a primary website, the platform can crawl reachable pages that begin with that base URL, such as /about, /funding, and /compliance. The pages do not need to be entered individually. A page outside that base URL, such as https://grad.arizona.edu/academics, is not crawled unless it is added separately as a primary or additional source.

If the primary website is https://research.arizona.edu, an exclusion such as https://research.arizona.edu/news/* prevents pages within the /news directory from being ingested while allowing other reachable pages under the primary website to be crawled. A specific page can also be excluded by listing its complete URL.

Supported downloadable documents are downloaded, their text is extracted, and the content is added to the assistant's knowledge base, even when the file is hosted outside the primary website.

Suppose a crawled page on https://research.arizona.edu links to https://externalorganization.org/policies/research-guide.html. The platform extracts its text and adds that content to the knowledge base. It does not crawl the rest of externalorganization.org. To ingest pages from that external website, the site must be added as a separate source.

The platform supports HTM, HTML, PDF, DOCX, PPTX, JSON, XML, TXT, Markdown, CSV, XLSX, and other commonly used file types.

No. It does not currently extract text embedded in infographics, flowcharts, organizational charts, or other images.

A public single-page application may return minimal HTML and load its visible text only after JavaScript runs in the browser. A standard crawler may not capture that text. If the same page includes its content in the initial HTML response, the text can be extracted. Teams should test representative pages before relying on a JavaScript-heavy site as a source.

Sources are re-scanned on a configurable schedule. The default is once per day. The appropriate frequency depends on source size, how often the content changes, and the time required to crawl and process it.

The current supported knowledge base size is approximately 100 GB per assistant.

Generally, no. Use the public website as the source when the information is already available there. Use Box for supplemental content that is not public or for documents the team wants to maintain separately.

Yes. Box content is crawled on the configured schedule, changes are detected, and the knowledge base is synchronized. Consolidated document in a well-organized Box folder provided for UITS is recommended for supplemental business knowledge.

A business unit can use its public website as the primary source for published services, policies, and contact information, then use the provided Box folder for supplemental material that is not publicly available or is maintained separately. For example, the website may supply public program pages while a consolidated Box document supplies internal routing guidance or FAQ or approved service descriptions. Routing rules themselves should remain in custom instructions.

Not automatically. This requires a custom data pipeline based on the source system, available APIs or integration methods, and the overall architecture. Delivery may take from one week to several months and may require additional funding.

Yes. The website crawler respects robots.txt files and other configured crawler restrictions.

Yes. URLs containing query strings, such as https://example.arizona.edu/page?id=123, can be configured for inclusion in or exclusion from the website crawl.

Yes. List a complete URL to exclude an individual page. To exclude all pages within a directory, add /* after the directory path. For example, https://example.arizona.edu/news/* excludes content within the /news directory.

Yes. The Data Sources & Services form allows multiple primary websites. List each website separately so its reachable pages can be crawled.

Its content is automatically removed from the assistant's knowledge during the next scheduled crawl and synchronization.

During the next scheduled crawl, the crawler removes content associated with the old URL and ingests content from the new URL, provided the new page is within the configured crawl scope or is otherwise included as a source.

No. Password-protected documents cannot be crawled or ingested into the assistant's knowledge base. Password protection must be removed before the document is provided as a knowledge source.

Only if the scanned PDF contains an extractable text layer. The platform does not currently extract text embedded only in images.

Users whom UITS has granted editing access to the provided Box folder or file can update its content. The business unit should limit access to authorized content owners and administrators.

The business unit owns the accuracy, completeness, currency, and approval of its source content. UITS manages the technical platform and ingestion process but is not the subject matter owner of the business unit's information.

The UITS technical team creates the initial draft based on the discovery meeting, documented requirements, data sources, services, routing rules, and expected assistant behavior. After launch, business unit administrators maintain and refine the instructions through the Admin Portal. UITS can assist when a requested behavior cannot be achieved through normal instruction changes.

The platform supports lengthy instructions. One existing assistant has approximately 15,000 words, and the platform supports significantly more.

Keep routing rules in the assistant's custom instructions rather than in the knowledge base. Organize them by unit, topic, or routing scenario so they are easier to maintain and refine.

Generally, yes, when the desired behavior is expressed clearly in natural language. Testing and iterative refinement are still required; instructions do not eliminate the need to validate behavior.

Yes. Configure the fallback response in the assistant's custom instructions, including any office, intake address, or escalation path users should contact.

Yes. Administrators can create as many suggested starter prompts as needed and update them through the Admin Portal.

Yes. A business unit may operate multiple assistants when it has substantially different audiences, knowledge sources, services, or routing requirements. Separate assistants can simplify maintenance and make behavior more predictable. Each assistant should have a clearly defined use case and may require separate onboarding and approval.

Yes. Custom instructions can direct the assistant not to answer defined topics and instead provide an approved referral, fallback response, or escalation path. These restrictions must be tested because natural-language instructions do not guarantee perfect behavior in every situation.

Instruction changes should be validated in the Test environment before promotion to Production. Testing should cover standard questions, edge cases, prohibited topics, routing scenarios, fallback behavior, and questions that previously produced incorrect responses.

Yes. Every assistant has a Test (TST) environment for configuration, appearance changes, knowledge synchronization checks, and response-accuracy testing before promotion to Live (Production).

Yes. Authorized business unit administrators can review, search, filter, download, and export conversation history through the Admin Portal. They can also review automated evaluation reports and metrics to identify incorrect or unclear responses.

There is currently no limit on the number of administrators designated for an assistant.

Administrators manage custom instructions and most assistant settings in the Admin Portal. Knowledge-source URLs, crawling, and automated accuracy-evaluation schedules are managed through the UITS support channel.

The end-user-facing assistant has been tested by the Disability Resource Center (DRC) and approved for accessibility.

Benchmark evaluations use predefined questions and expected responses or evaluation criteria. The platform runs the questions against the assistant and compares the actual responses with the expected results to produce evaluation reports and metrics.

Yes. Business unit administrators can configure benchmark evaluations to run on their preferred recurring schedule. The schedule should reflect how frequently source content and instructions change.

Yes. Business unit administrators can subscribe to email alerts when an automated evaluation score falls below a defined accuracy threshold.

The platform can send an email notification when a user dislikes a response. The notification includes the conversation and highlights the negatively rated response so administrators can investigate and refine instructions or knowledge sources.

Authorized business unit administrators can access conversation transcripts. A business unit leader or current administrator must ask UITS to add or remove an administrator, and UITS completes the requested access change.

No. Conversation data from ArizonaAI Platform assistants is not used to train external AI models.

Yes. UITS can restore a previous version of an assistant's instructions upon request. Business unit administrators can restore previous style settings directly through the Admin Portal.

A business unit administrator can take an assistant offline at any time through the Admin Portal and return it online when it is ready for use again.

Yes. Any link, button, or other HTML element on a page where the chatbot is loaded can open or close the AI assistant. No additional JavaScript is required—the chatbot automatically adds the click behavior after it loads. The opener will work only on pages where the chatbot itself is installed and successfully initialized.

Yes. The chatbot can be styled to align with your unit’s website and branding. Customization options may include colors, logos, welcome messages, chatbot icons, window placement, and other interface elements.

Yes. Department-approved logos and brand colors can be incorporated into the chatbot interface. All styling should follow University of Arizona branding and accessibility standards.

Yes. You can choose a chatbot name and create a welcome message that clearly explains its purpose, intended audience, and scope of assistance.

The chatbot can be displayed as a chat bubble or embedded within a webpage, depending on the website design and implementation requirements. Placement can be selected to support visibility without interfering with the page’s primary content.

Yes. The chat icon and conversation window can be customized to support the desired user experience. Available options may depend on the website platform and chatbot configuration.

Yes. The chatbot interface is designed to work across desktop, tablet, and mobile devices. Styling should be tested at different screen sizes to ensure that the chatbot remains readable and easy to use.

Yes. The platform provides business administrators with self-service tools to update the chatbot’s styling after deployment as branding, content, or usability needs change. More complex updates may require assistance from the chatbot support team.

Each chatbot can be configured for public access or restricted access. Restricted options include University of Arizona WebAuth, Microsoft Entra single sign-on (SSO), chatbot-specific local accounts, role-based access, and Brightspace D2L class enrollment.

Yes. Access to a chatbot can be limited to users with a University NetID, members of a specific team, authorized external users, or students enrolled in a particular class. The appropriate access method is selected and applied when the chatbot is configured.

Yes. A chatbot can be configured to limit access to students listed on the class roster for a designated Brightspace D2L course. Users must authenticate through Brightspace D2L using the University account associated with their course enrollment.

A local login may be used when authorized users do not have a University NetID or another supported SSO account. These credentials are specific to the chatbot and are managed separately from University accounts. Local access should generally be reserved for approved use cases where institutional SSO is unavailable.

Only when the chatbot’s configuration permits it. Approved external users may be given a local account authentication method. Having the chatbot’s web address alone does not grant access.

Examples include Housing, Tech Launch Arizona, and the Graduate College Assistant, each of which incurs less than approximately $3 per month in token costs. Actual cost depends on usage and should not be estimated solely from those examples. UITS will cover the token cost when it is not significantly higher than approximately $5 per month.

If recurring operating cost is expected to exceed approximately $5–$10 per month, the unit would need to provide its own API account to cover usage.

Yes. Leadership approval should be obtained before the assistant moves into configuration and development. An initial demonstration and discovery meeting may occur before approval so leadership can understand the use case, requirements, responsibilities, and expected effort.

There is no fixed timeline. It depends on the number and complexity of knowledge sources, content readiness, instruction-development needs, and the time required for business-unit testing and refinement. The initial discovery meeting normally takes about one hour. After testing and approval, production deployment takes approximately 15 minutes, while crawling and processing knowledge sources may take several hours.

Onboarding usually includes a one-hour kickoff meeting for a platform demonstration, business use-case and requirements discovery, and a review of steps and expectations; leadership approval; completion of the Data Sources & Services form; initial configuration and knowledge ingestion; an initial custom-instructions draft; internal testing, instruction refinement, and response-accuracy validation; and production deployment.

The business unit is responsible because its subject matter experts understand its services, policies, and requirements. Subject matter experts evaluate responses, while business unit administrators coordinate testing and refine instructions and knowledge sources before production deployment.

List primary websites, exclusions, additional sources (including approximate size, location, and file types), and the services or support areas the assistant should cover.

Yes. Multiple business units can jointly own and manage one assistant. The participating units should establish clear responsibilities for administration, source-content ownership, testing, approvals, and ongoing maintenance.

The designated business owner is a representative of the requesting business unit who has authority over the assistant's use case, source content, and operational decisions. This person coordinates subject matter experts, approves the assistant's behavior, and ensures that administrators maintain it after launch.

Business unit administrators maintain instructions and assistant settings; coordinate subject matter experts; validate response accuracy; review conversations, evaluations, and feedback; refine knowledge and instructions; configure benchmarks and alerts; report source or platform issues to UITS; and ensure the assistant continues to meet the business unit's needs.

During onboarding, UITS provides the platform demonstration, use-case and requirements discovery, initial configuration, knowledge-source setup, an initial custom-instructions draft, technical guidance, and production deployment support. After launch, UITS handles platform-level issues, knowledge-source URL changes, access changes, instruction-version restoration, and other changes not available through the Admin Portal. Routine content validation, instruction refinement, testing, and monitoring remain the business unit's responsibility.