-
Notifications
You must be signed in to change notification settings - Fork 19
Table
Most Caseflow users' default view is to see cases assigned to them in a table. We have a few iterations of this table based on user type.
All users should have the following:
- Veteran identifiers:
- Veteran name
- Veteran ID ( == VBMS ID, Claim number, SSN)
- Urgency indicators:
- Appeal type (e.g. AOD)
- Docket number
- Legislative / procedural indicators:
- AMA vs. legacy docket - appended to docket number Timeliness nudges:
- Days waiting = days since the case was assigned or reassigned to a judge
Attorneys currently have the following columns:
- Case details: Veteran name | Veteran ID
- Type: AOD, CAVC, Original, Post-Remand, etc.
- Docket number:
- Days waiting:
- Veteran documents: Link to Reader
This view allows judges to see cases assigned to them to review and sign.
- Case details: Veteran name | Veteran ID
- Document ID: Document ID and attorney who assigned the case to the judge
- Type: AOD, CAVC, Original, Post-Remand, etc.
- Docket number:
- Days waiting:
- Veteran documents: Link to Reader
- Case details: Veteran name | Veteran ID
- Task Type: Admin action type
- Type: AOD, CAVC, Original, Post-Remand, etc.
- Docket number:
- Days waiting:
- Veteran documents: Link to Reader
Field | Attorney | Judge cases to sign | Judge cases to assign/attorney queues | Co-located |
---|---|---|---|---|
Veteran name (ID) | x | x | x | x |
Appeal type (e.g. AOD) | x | x | x | x |
Docket number | x | x | x | x |
Task type | x | x | ||
Number of issues | x | x | x | |
Number of documents | x | x | ||
Document ID | x | |||
Evaluation of waiting / assigned (x days ago, date assigned) | x | x | ||
Due date | x | |||
Assigned from an attorney | x |
Cases are shown in user's queue tables as tasks. These indicate the action that a user is expected to take on the case that is assigned to them. This allows cases to be show in multiple users' queues at the same time, if the work on them can be done in parallel. For AMA appeals, all tasks exist in the caseflow database. Currently, legacy appeals that are assigned to a judge or an attorney do not have tasks in the caseflow database. Instead, we use information from vacols such as the case's "location" and the user's role as a judge or an attorney to determine whose queue the case should appear in and what actions they should be able to take on the case. These are known as legacy "ephemeral" tasks; they are not stored as tasks but are formed into a similar format based on information from vacol so tables can present them as tasks. This causes some occasional annoyance for users that are "acting" judges as they can perform both attorney and judge work.
These cases are paginated on the back end (with the exception of judge and attorney "Assigned" tabs and a judge's entire assign queue). This means the initial request to load a user's queue will only pull and show the first 15 tasks in their assigned tab based on the standard case sort order (high priority first, then oldest). Any subsequent navigation to other tabs, filtering, or sorting of tasks will make requests to the back end for these appeals to keep the initial load time of queues down.
This tab shows all active tasks assigned to a user. This is determined by the task having an active status and the assignee being the user. As noted above, as attorney and judges do not have tasks stored in caseflow for legacy appeals, this tab will also show any legacy appeals with a location code of the user's unique vacols id.
This tab shows any case that is assigned to a user that is currently on hold, either because the user placed the case on a timed hold (will become available to be worked after that time is up) or they have assigned a task to another person or team (will become available to be worked when that work has been completed). For legacy appeals, we populate attorney on hold legacy appeals by looking for any tasks they have assigned to their support team (as what would have been that task's on hold parent assigned to the attorney does not exist in the caseflow DB).
This tab shows every task that the user has completed in the last two weeks. If the user cancelled a task, it will not appear in this tab.
This tab shows all active tasks assigned to the organization that has not been assigned to a member of that org. This is determined by the task having an active status and the assignee being the organization.
This tab shows all active tasks assigned to the organization that have been assigned to a member of that org and are currently being worked.
This tab shows any case that is assigned to a member of the organization that is currently on hold, either because the user placed the case on a timed hold (will become available to be worked after that time is up) or they have assigned a task to another person or team (will become available to be worked when that work has been completed).
This tab shows every task that every member of the organizatrion has completed in the last two weeks. If the user cancelled a task, it will not appear in this tab.
- Home
- Acronyms and Glossary
- Caseflow products
- Caseflow Intake
- Caseflow Queue
- Appeals Consumer
- Caseflow Reader
- Caseflow eFolder
- Caseflow Hearings
- Caseflow Certification
- Caseflow APIs
- Appeal Status API
- Caseflow Dispatch
-
CSUM Roles
- System Admin
- VHA Team Management
- Active Record Queries Resource
- External Integrations
- Caseflow Demo
- Caseflow ProdTest
- Background
- Stuck Jobs
- VA Notify
-
Caseflow-Team
- Tier 4
- Bat Team
- Technical Documentation
- Backend Code Patterns
- Backend Working Group
- FACOLS, VACOLS DB Schema
- Asyncable Models
- External Data: where and why
- Data Fetching Scripts
- Caseflow Data Model and Dictionary
- User Access Permissions
- Controller Schemas
- Constants
- Frontend Best Practices
- Accessibility
- How-To
- Debugging Tips
- Adding a Feature Flag with FeatureToggle
- Editing AMA issues
- Editing a decision review
- Fixing task trees
- Investigating and diagnosing issues
- Data and Metric Request Workflow
- Exporting and Importing Appeals
- Explain page for Appeals
- Record associations and Foreign Keys
- Upgrading Ruby
- Stuck Appeals
- Testing Action Mailer Messages Locally
- Re-running Seed Files
- Rake Generator for Legacy Appeals
- Manually running Scheduled Jobs
- System Admin UI
- Caseflow Makefile
- Upgrading Postgresql from v11.7 to v14.8 Locally
- VACOLS VM Trigger Fix M1
- Using SlackService to Send a Job Alert
- Technical Talks