Provide all of the steps you would take to analyze feedback from users of an existing application, plan design changes, and complete a refactor of the application.

At your firm's financial services client, a senior transaction advisory group has complained about an existing application.

1. The group handles hundreds of high-value, current financial transaction approvals, related to many thousands of previously approved clients. Because these transactions are time-sensitive, multiple executives often monitor the same queue simultaneously to complete reviews assigned to their group.
2. Their primary issues are not knowing when tasks are completed by other group members, abandoned tasks that have an "in progress" status, delayed task completion time, lack of transparency into assigned tasks, and an inability to reassign tasks they've accepted.
3. Additionally, the group complains about load times for the high volume of data they manage, and irrelevant transactions and tasks showing in their dashboard. 

I would split the refactoring into four parts: delivery methodology, task locking and UI/UX, performance, and testing and deployment.

Delivery methodology

I would start by meeting the advisory group to hear their feedback and find the root causes of the problems. Then I would review the current application: process models, interfaces, task assignments, record types, and database queries.

From those findings I would:

1. Document the existing issues and the improvements the group expects.
2. Write user stories with acceptance criteria.
3. Prioritize the changes by business impact.
4. Review design options with the business, especially optimistic versus pessimistic locking.
5. Estimate the effort and plan the sprints.
6. Get business approval before implementing.

Because several executives work the same approval queue, preventing duplicate approvals and handling abandoned tasks would be high priority.

Task locking and communication UI/UX

Task locking

Since multiple executives monitor the same transaction queue, I would compare two approaches. With optimistic locking, several users can open a transaction, and the system checks for changes before saving to prevent conflicting updates. With pessimistic locking, once a user accepts or starts a transaction, nobody else can modify it until the lock is released. Pessimistic locking probably fits here because the transactions are high value and time sensitive.

Appian already supports task acceptance for group-assigned User Input Tasks: once the required number of users accepts a task, other group members can’t accept it. If the application uses custom approval interfaces instead of standard tasks, I would build a database-backed lock, using a table or stored procedure to track the owner and block concurrent updates. The flow would be:

1. Executive A opens and accepts Transaction 1001.
2. The application records Executive A as the owner.
3. Executive B sees that Transaction 1001 is under review.
4. Executive B cannot approve it at the same time.
5. When Executive A completes it, the status updates and the lock is released.

Abandoned tasks and reassignment

I would configure Appian task escalations and reassignment permissions. If an executive accepts a task and doesn’t finish it within the agreed time, Appian can send a notification or reassign the task to another authorized user or group. Executives would also get the permissions they need to return or reassign tasks they have accepted. For custom locks, I could add an expiration, but it would have to confirm the transaction isn’t actively being processed before releasing ownership.

UI/UX improvements

The approval dashboard would show the transaction ID and approval status, the assigned executive, priority and due date, whether the task is available or already accepted, and options to reassign or return it, depending on permissions. Notifications would go out when tasks are assigned or reassigned and when approvals are completed. The dashboard should refresh task information so executives can see completed transactions without checking manually.

Performance improvements

With thousands of clients and hundreds of active transactions, I would start with the slow dashboard queries. The checks:

1. How many records the dashboard retrieves on load
2. Whether the queries pull unnecessary fields and relationships
3. Whether they have proper filters and pagination
4. Whether the database has appropriate indexes
5. Whether synchronized record types could help

Then I would narrow what gets retrieved. Instead of fetching all previously approved client transactions, I would return only those relevant to the current executive or group, filtered by assigned group, region, industry, transaction status, and approval priority. Pagination would load 25 or 50 transactions at a time rather than thousands.

On the database side, I would review joins, optimize slow queries, and move complex calculations into the database where it makes sense. Appian’s performance monitoring tools would show which queries and interface evaluations are expensive.

Testing and deployment

I would test the full approval workflow, including:

1. Two executives trying to accept the same task
2. An executive abandoning an accepted task
3. A manager reassigning an overdue approval
4. Completed transactions leaving the active queue
5. Dashboard performance under large transaction volumes

After that I would run UAT with the advisory group, deploy the approved changes, and monitor performance.

Supported by Appian's documentation on task acceptance and reassignment, User Input Task configuration, and record query filtering and performance.