Kartorium Docs

My Shifts Complete Time Entry Flow

4 min read

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:

  • 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.

3. Job entry with no other open people

If the user is the last open time entry on that batch instance:

  • inspect downstream stations
  • determine whether the same batch number already has an unresolved downstream instance

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.

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.

See Also

Graph View

Backlinks