Initial data entry after deployment

Rediflow: Project flow. Portfolio flow. One flow.

Feed the system with initial data after deployment. You don't need to do everything at once — start small, add more when you need it. Each step covers: What to do, Why it matters, How to do it, and How to verify it worked.

After entering data, use Data quality monitoring (Project → Settings → Data quality check, or Settings → Data quality monitoring) to verify and resolve issues. See Fix data quality errors.

Screenshots are auto-generated; your UI may vary slightly.


Phase 1: First-time user (minimum to get going)

Step 1: Prerequisites

What: Ensure migrations have run and the app is started.

Why: The database must have the schema and project lifecycle states before you add data.

How:

  1. Start PostgreSQL (e.g. podman compose up -d).
  2. Set DATABASE_URL in your environment (e.g. .env.dev).
  3. Run uv run python main.py migrate.
  4. Optionally run uv run rediflow seed-calendars for country holidays (FI, SE).
  5. Start the app: uv run python main.py run.
  6. Open http://127.0.0.1:5000 in your browser.

When using container deployment (QA or production): The app and database start with the stack. Run migrations and seed-calendars inside the container. See Deploy QA and production and Seed projects and calendars for the full workflow.

Verify: The home page loads. If setup info is shown, you're ready to add data.

Home page after app starts


Step 2: One organisation

What: Add at least one organisation (we use Example_com in this guide).

Why: Without an organisation, you cannot set a Project Owner Organisation (POO) when creating a project. The POO identifies who owns each project.

How:

  1. Go to Settings (top navigation).
  2. Click ORGS.
  3. In the last row of the table, enter Example_com in the Short name column.
  4. Click Save.

Screenshot: ORGS list with Example_com

Verify: You see Example_com in the ORGS list. You can also create an organisation on-the-fly when creating your first project (type a short name in "Or new org").


Step 3: Role type group and role type

What: Add one role type group and one role type (e.g. "Default" and "PM").

Why: Role types power the "Home organisation role" on tasks and milestones. Without them, those dropdowns stay empty.

How:

  1. Go to SettingsRole type groups.
  2. In the new row, enter Default as the group name. Click Save.
  3. Click Edit role types.
  4. In the new row, select the Default group, enter code PM and label Project Manager. Click Save.

Screenshot: Role type groups

Screenshot: Role types

Verify: You see the Default group and the PM role type. You can add more later.


Step 3a: Home organisation role group and home organisation roles

What: Add one home organisation role group and at least one home organisation role (e.g. "Default" and "Lead").

Why: The "Home organisation role" column on tasks, milestones, and deliverables needs these. Without a group and roles linked to it, that dropdown stays empty. Projects select a home organisation role group in settings; only roles from that group appear in the dropdown.

How:

  1. Go to SettingsHome organisation role groups.
  2. In the new row, enter Default as the group name. Click Save.
  3. Click Edit home organisation roles.
  4. In the new row, select the Default group, enter code Lead and label Lead. Click Save.
  5. Add more roles as needed (e.g. Ben, n/a).

Verify: You see the Default group and at least one home organisation role. When creating a project, set Home organisation role group in Project → Settings → Project schemes so the Home organisation role column shows these roles.


Step 4: Deliverable type group and deliverable type

What: Add one deliverable type group and one deliverable type (e.g. "Default" and "R" for Report).

Why: Required for the Deliverables sheet. Projects can later restrict to a specific group in their scheme.

How:

  1. Go to SettingsDeliverable type groups.
  2. Add group Default. Click Save.
  3. Click Edit deliverable types.
  4. Add type R with label Report in the Default group. Click Save.

Screenshot: Deliverable type groups

Screenshot: Deliverable types

Verify: You see the Default group and the R type.


Step 5: Dissemination level group and dissemination level

What: Add one dissemination level group and one level (e.g. "Default" and "PU" for Public).

Why: Required for the Deliverables sheet (dissemination column). Same idea as deliverable types.

How:

  1. Go to SettingsDissemination level groups.
  2. Add group Default. Click Save.
  3. Click Edit dissemination levels.
  4. Add level PU with label Public in the Default group. Click Save.

Screenshot: Dissemination level groups

Screenshot: Dissemination levels

Verify: You see the Default group and the PU level.


Step 6: Create first project

What: Create your first project with name, duration, dates, and Project Owner Organisation (POO).

Why: Projects are the core unit. You need at least one to add work packages, tasks, milestones, and deliverables.

How:

  1. Go to Projects (top navigation).
  2. Click New project.
  3. Enter Name (e.g. "First project"), Duration (months) (e.g. 12), Planned begin and Planned end dates.
  4. Select Project Owner Organisation (POO) = Example_com (or type a new organisation name in "Or new organisation").
  5. Click Create project.
  6. Open the project → SettingsProject schemes. Set Home org role group = Default (and optionally Role type group, Deliverable type group, etc.) so the Home org role column on tasks, milestones, and deliverables shows the roles you added.

Screenshot: New project form

Screenshot: Project settings after creation

Verify: The project opens and you see project settings. You can now add WPs, tasks, etc. when ready.


Phase 2: Add tasks and deliverables

Step 7: One work package

What: Add one work package (WP) to your project.

Why: Tasks belong to a work package. You need at least one WP before adding tasks.

How:

  1. Open your project.
  2. Click WPs in the project sub-navigation.
  3. In the new row, enter 1 for WP # and Management (or any name) for WP Name.
  4. Click Save.

Screenshot: WPs sheet with one WP

Verify: You see WP1 in the WPs sheet.


Step 8: One task

What: Add one task under the work package.

Why: Tasks are the unit of work. Adding one verifies the flow and lets you use capacity demand.

How:

  1. Click WPs+Tasks in the project sub-navigation.
  2. In the "New task" row, select WP1, enter task ID 1.1 and name Project coordination.
  3. Click Save.

Screenshot: WPs+Tasks sheet with one task

Verify: You see the task under WP1. You can optionally add milestones and deliverables next.


Phase 3: Add more projects

Step 9: Second and third projects

What: Create two more projects (up to three total), all with POO = Example_com.

Why: A portfolio typically has multiple projects. Keeping them under one org first keeps setup simple.

How:

  1. Go to ProjectsNew project.
  2. Create Second project (duration, dates, POO = Example_com). Save.
  3. Create Third project (duration, dates, POO = Example_com). Save.

Screenshot: Projects list with three projects

Verify: The projects list shows three projects; all owned by Example_com.


Phase 4: Full org structure

Step 10: Add org branches

What: Add BranchA and BranchB as children of Example_com.

Why: A hierarchy lets you organise projects by business unit. Child orgs inherit country code and non-working days from the parent.

How:

  1. Go to SettingsORGS.
  2. In the new row, enter BranchA, set Parent = Example_com. Click Save.
  3. In the new row, enter BranchB, set Parent = Example_com. Click Save.

Screenshot: ORGS with full hierarchy

Verify: The ORGS list shows Example_com with BranchA and BranchB as children.


Phase 5: Projects across org branches

Step 11: Assign projects to branches

What: Change project 2's POO to BranchA and project 3's POO to BranchB.

Why: Distributes projects across the org structure. Demand and portfolio views can filter by org.

How:

  1. Open Second projectSettings.
  2. Change Project Owner Organisation (POO) to BranchA. Click Save.
  3. Open Third projectSettings.
  4. Change Project Owner Organisation (POO) to BranchB. Click Save.
  5. Go to Demand (or Graph → project view) to see projects by org.

Screenshot: Demand view with projects across org branches

Verify: Demand/portfolio views show projects distributed across org branches.


Checklist

Phase 1–2 (first-time user):

  • [ ] Migrations + seed-calendars
  • [ ] One org Example_com (or create on first project)
  • [ ] One role type group + one role type
  • [ ] One home org role group + one home org role (linked to that group)
  • [ ] One deliverable type group + one deliverable type
  • [ ] One dissemination level group + one dissemination level
  • [ ] First project (name, duration, dates, POO = Example_com)
  • [ ] (Optional) One WP, one task
  • [ ] Verify: project opens, task visible

Phase 3 (more projects):

  • [ ] Second project (POO = Example_com)
  • [ ] Third project (POO = Example_com)
  • [ ] Verify: three projects in list

Phase 4 (full org structure):

  • [ ] Add BranchA, BranchB as children of Example_com
  • [ ] Verify: org hierarchy visible

Phase 5 (projects across branches):

  • [ ] Project 2 → POO = BranchA
  • [ ] Project 3 → POO = BranchB
  • [ ] Verify: Demand shows projects by org

Add when needed (Phase 6)

  • WBS — Participant orgs and PMs per WP when you need capacity breakdown.
  • WP themes, Task themes, Task type of action — For categorising work packages and tasks.
  • Person capacity (if enabled) — Employee groups, allocation groups, people, team, role demand.

See also