Inspiration
Visa applications often require users to move across multiple systems, gather sensitive documents, and complete high-stakes submission steps with very little clarity around what is happening, what is missing, and what actions are being taken on their behalf. I wanted to build a workflow where identity, consent, and document access feel secure and understandable instead of fragmented and risky.
VisaPilot was inspired by a simple idea: sensitive actions should not feel invisible. If a user is attaching a supporting document, reviewing an application, or preparing a final submission, the system should make those steps explicit, auditable, and easy to follow.
What it does
VisaPilot is a secure visa workflow assistant that uses Auth0 for protected identity and controlled access, while helping users move through a visa preparation flow with a clearer operational workspace.
The current experience includes:
- protected application access with Auth0
- a review and submit workspace for visa preparation
- assistant guidance for missing steps
- an action center for document-related tasks
- a real Google Drive document selection flow
- attachment of a selected PDF into the submission package
- visible audit and approval-oriented workflow framing
A user can sign in, review their application state, select a real supporting PDF from Google Drive, and see that document attached into the visa review package before final submission.
How we built it
Architecture Flow
User opens VisaPilot
↓
VisaPilot Frontend (Next.js)
↓
Auth0 Login
↓
Protected Session Created
↓
Protected Workflow Workspace
↙ ↓ ↓ ↘
Dashboard Assistant Review & Submit Audit Log
↓
User clicks Pick PDF from Google Drive
↓
Google Drive Picker opens
↓
User selects real PDF
↓
PDF metadata returns to VisaPilot
↓
PDF attached to submission package
↓
Visible package update
↓
Audit trail updated
↓
Submission readiness improves
↓
Final submission remains approval-aware
VisaPilot was built as a secure workflow application with:
- Next.js for the frontend and application structure
- Auth0 for authentication, identity protection, and workflow security framing
- Google Drive integration for real supporting document retrieval
- a review-oriented UI that highlights missing items, submission readiness, and delegated action visibility
Auth0 was central to the project. It was used to protect the application experience, manage user sessions, and frame delegated actions in a way that is safer and more explicit for sensitive workflows.
For the real external action, I integrated Google Drive so that a user can select an actual PDF and attach it to the visa submission workflow. This made the demo more than a static mock: it shows a real document access flow inside a protected application.
Challenges we ran into
The hardest part of the build was designing a delegated external-access flow that felt secure and demo-ready at the same time. I explored a deeper Token Vault-based connected-account flow through Auth0, including protected token exchange patterns and Google connection handling. That path surfaced practical issues around refresh-token storage, connected-account state, and external provider behavior during testing.
Rather than leave the project in a fragile state, I pivoted to a more reliable real integration path: keeping Auth0 for protected identity and workflow security while using a direct real Google Drive selection flow for the supporting document action. This kept the project aligned with the core goal of secure, consent-based delegated actions while ensuring the demo remained stable and meaningful.
Another challenge was making the system feel operational instead of purely visual. I wanted the selected document to visibly affect the review package, status flow, and action history so the result looked like a true workflow action, not just a disconnected file picker.
What we learned
This project reinforced that secure workflow design is not only about authentication. It is also about making sensitive actions understandable, bounded, and visible to the user.
I learned a lot about:
- Auth0 application setup and protected session flows
- delegated-action design patterns
- tradeoffs between ideal architecture and demo reliability
- how real external integrations shape UX decisions
- the importance of making security visible through review states, approval logic, and audit-oriented interaction design
What’s next for VisaPilot
The next step is to expand VisaPilot into a stronger approval-aware workflow platform with:
- richer audit logs and action history
- approval gates for final submission
- deeper delegated integrations for document sources
- stronger role separation between applicant, assistant, and reviewer
- more complete submission readiness logic
- expanded document validation and checklist intelligence
The long-term vision is a secure workspace for high-stakes application processes where Auth0-powered identity, explicit consent, and auditable delegated actions help users move through sensitive workflows with more confidence and less friction.
Bonus Blog Post Submission: Token Vault, Delegated Access, and VisaPilot
VisaPilot was designed around a simple but important idea: in a high-stakes workflow, sensitive actions should not feel invisible. In a visa preparation process, users often move across multiple systems, gather documents manually, and lose visibility into what is missing, what has already been attached, and what is happening before final submission. That is exactly where Auth0’s delegated-access model became important in shaping this project. The project description already focuses on protected identity, explicit document actions, and auditable workflow steps, and this bonus section explains the Token Vault-related direction behind that design in more detail.
While building VisaPilot, I explored a deeper Token Vault-based connected-account path through Auth0 for AI Agents. The reason this mattered is that VisaPilot is not just a login-protected dashboard. It is meant to be a secure workflow system where external document actions happen on behalf of the user in a way that remains bounded, understandable, and reviewable. In this case, the external action is a supporting-document retrieval flow connected to Google Drive. Instead of treating that action like a hidden backend event, the product is designed to make it visible in the review workflow: the user initiates the action, the document is selected, the package updates, and the audit trail reflects the change.
The Token Vault direction was important because it represented the strongest version of that delegated-action model. It raised real implementation questions around consent delegation, connected-account state, refresh-token handling, and provider-specific behavior. Working through those challenges reinforced an important lesson: secure workflow design is not only about authentication. It is also about how identity, consent, and external actions are presented to the user. A technically powerful integration is only useful if the resulting action remains visible and trustworthy from the user’s perspective.
For the final demo, I prioritized a stable workflow experience while preserving the core product principle that came from this Token Vault exploration: protected identity, explicit consent, and real external document access should come together in one auditable workspace. That is the main achievement I would highlight from this project. VisaPilot applies Auth0 not just as a sign-in layer, but as the identity foundation for safer delegated actions in a sensitive application process.
Built With
- auth0
- google-drive-api
- google-picker
- next.js
Log in or sign up for Devpost to join the conversation.