My Shifts Complete Time Entry Flow
ops job time-tracking my-shifts lifecycle
This note captures the current design for what should happen when a user clicks an open entry on /my-shifts and completes it.
The important distinction is:
- completed entries should still open the normal Edit Shift modal
- open entries should open a dedicated Complete Time Entry modal
For job-linked entries, completion has to respect the station graph and downstream unresolved job instances.
High-Level Completion Flow
flowchart TB A["User clicks an entry on /my-shifts"] --> B{"Is the entry already completed?"} B -- Yes --> C["Open Edit Shift modal"] B -- No --> D["Open Complete Time Entry modal Same general shape as Add Time end date/time required"] D --> E["User submits completion"] E --> F{"Is this a job-linked entry?<br/>(job vs activity)"} F -- No --> G["Clock out / complete time entry only"] F -- Yes --> H["Load batch context for this entry"] H --> I{"Are there other open time entries on this same batch?"} I -- Yes --> J["Complete only this user's time entry Leave batch/job otherwise unchanged"] I -- No --> K["Treat this like complete job flow"] K --> L{"Are there unresolved matching jobs on downstream stations?"} L -- Yes --> M["Complete this user's time entry Mark this station's job as resolved Do not leave this as the active unresolved job"] L -- No --> N1{"Does this station have any outbound connections?"} N1 -- Yes --> N["Complete this user's time entry Complete job like Complete Job modal Make sure to leave it unresolved"] N1 -- No --> M G --> R["Reload My Shifts"] J --> R M --> R N --> R
Core rule
The active unresolved job instance should generally live at the furthest downstream station in the chain, unless earlier stations still have active people working on their own open time entries.
That means completion on My Shifts cannot just blindly:
- clock out the current user
- or always complete the station instance
It has to understand where the same batch number exists elsewhere in the station graph.
Decision rules
1. Activity entry
If the open entry is not job-linked:
- just complete the time entry
- no batch instance logic applies
2. Job entry with other open people still on it
If another open labor entry exists on the same batch and all labor is done is not selected:
- complete only the current user’s time entry
- do not change the job instance
This avoids one operator accidentally closing or resolving a station instance while other people are still actively working on it.
If all labor is done is selected from the My Shifts table or from the Complete Time Entry modal:
- clock out every open labor entry for the same job number at the same station
- set the shared end timestamp to the nearest 15-minute mark
- leave open labor entries for other jobs or other stations unchanged
- leave already closed labor entries unchanged
- complete the current station’s job instance
- automatically create the downstream staging station job when there is exactly one downstream staging station and no other station has active labor for the same job
3. Job entry with no other open people, or all labor done
If the user is the last open time entry on that batch instance, or selected all labor is done:
- inspect downstream stations
- determine whether the same batch number already has an unresolved downstream instance
- determine whether another station still has active labor for the same job number
4. Downstream unresolved instance exists
If the same batch number is already unresolved downstream:
- complete this user’s time entry
- resolve the current station instance
This means the current station should no longer be the active unresolved instance.
5. No downstream unresolved instance, but station has outbound connections
If there is no downstream unresolved instance yet, but this station can still feed into later stations:
- complete this user’s time entry
- perform the station-level completion behavior
- leave this station instance unresolved
That keeps this instance as the furthest active unresolved job instance in the chain.
When the user explicitly selected all labor is done, the station-level completion can also auto-stage the job. The auto-stage happens only when:
- the current station has exactly one downstream station
- that downstream station is a passive staging station, with batch operators disabled and batch equipment restrictions disabled
- no other station has an open labor entry for the same job number
If another station still has active labor for the same job number, My Shifts completes the current station only. The job waits at the other active station until that operator completes their time entry with all labor is done selected.
6. Terminal station
If the station has no outbound connections:
- complete the user’s time entry
- resolve the current station instance
This is the end-of-line case.
Downstream station check
The downstream check must be based on:
- station / equipment connections
- their configured direction
- the same organization
- the same site
- the same batch number / RMA
- unresolved, non-aborted downstream instances
It should not be based on visual position in Process Flow.
Current station-instance semantics
When we say resolve this station’s job instance, we mean:
- preserve the historical event and batch details
- mark that station instance as no longer the unresolved active instance in process flow
When we say complete job like Complete Job modal but leave unresolved, we mean:
- apply the normal completion behavior for the current station instance
- but do not remove its unresolved role yet, because it is still the furthest active station instance
Why this flow exists
My Shifts completion is not always the same as clicking Complete Job in Process Flow.
On My Shifts, the user is acting on a time entry first. The system then decides whether that should also affect the underlying station instance.
That keeps the labor-entry workflow and the process-flow lifecycle aligned.