This page describes the key flows in the single sourcing solution.

Please go through this for the key terminology, problem statement and the solution. Please go through this for the user roles in sourcing solution.

Overview

All the sourcing activities by a sourcing organization are done through a single “sourcing” portal. All the contribution activities by contributors (individuals or organizations) are done through a single “contribution” portal.

Note: A sourcing organization can get contributions from its own users also through “contribution” portal.

All sourcing activities happen only as a part of a “sourcing project”. This is to enable organizations to manage the sourcing activities in an efficient and controlled manner and the activities can be tracked for closure.

The sourcing actions are primarily of three types:

1. Seek assets for certain target collections - An example of this is getting assets for a set of Digital Textbooks or Courses. The collections might already exist or they have to be newly created.

2. Seek assets NOT specific to any target collections - An example of this could be getting assets of specific type or for specific purpose, like getting all the TV lessons uploaded.

3. Improve existing assets- This is typically done by analyzing consumption data and reviewing existing assets for improving the quality of the existing assets.

A sourcing project can be created for any of the above activities. A sourcing project consists of:

1. The objective of the project - Specified as one of the above three types of actions

2. Scope of the project - This is specified in terms of “what” and/or “whom for” regarding the assets that are being sought or that need improvement.

3. Schedule - Schedule in terms of the timelines of various activities within the project

Overall Sourcing Flows

When a sourcing admin creates a project, the above three options are provided for the user to choose. The flow for the rest of the project will be based on the chosen option.

Seek assets for target collections

Any project to seek assets for target collections has five stages as defined in the following sections. The project moves from one stage to the other stage by admin explicitly moving it to the next stage.

Note:

1. Sourcing orgs can create multiple projects to seek assets for the same target collection. However collections that are in “working in progress” state cannot be added as target collections.

2. When a collection is added as target collection, if there is no draft version of the collection, a draft version is automatically created by the system.

3. None of the changes made to the collection structure are reflected in any of the other existing projects where this collection is a target collection.

4. The changes made to the collection structure are reflected in the master draft version of the collection.

5. The collection (existing or newly created) can be modified as long as the project is in the prepare target collections stage. Once it is moved from this stage to next stage, there cannot be any modifications done.

Stage 1: Prepare target collections

Stage 2: Define Scope and Schedule

1. When a project comes to this stage, a version of the collections local to this project is created. All contributions are linked to this local version only by default.

2. When an linked asset is approved, it is linked to the master draft version of the collection.

3. None of the changes made to the collection structure from another project are reflected here in the local version.

Stage 3: Seek assets for target collections, review, publish

Note

1. When the assets are approved, they are published to consumption repo (if not already published).

Stage 4: Publish target collections

When a user tries to review and publish a collection, the system shows the master draft version. Hence it will have all the assets linked to it across all the projects, not just this project.

When the collection is published for consumption, it is linked with all the assets approved across all the projects at the time of publishing.

Once a collection is published, if the collection is a target collection for any other project, a draft version is automatically created by the system.

Stage 5: Close Project

Once the project is closed, it becomes “view only”. No operations can be performed through it.

Seek assets NOT for target collections

Seeking assets not for any target collection consists of only three stages as described in the following sections. The flow is exactly same as that of seeking assets for target collections - without the stages of preparing target collections and publishing target collections.

Currently the asset categories that can be selected are only non-collection categories.

Framework values come from the frameworks configure in the sourcing organization.

Stage 1: Define Scope and Schedule

Stage 2: Seek assets, review, publish

Note

1. When the assets are approved, they are published to consumption repo (if not already published).

Improve existing assets

This is a project to improve existing assets - which consists of reviewing, updating if required and publishing. It can also include deleting existing assets.

Stage 1: Define Scope and Schedule

Stage 2: Improve assets

Assets published by the sourcing organization can only be added.

1. Deleting asset should retire the asset in sourcing and consumption repos.

Work in progress state of an asset

Work in progress state is a flag populated to an asset to ensure the asset is not getting modified simultaneously from two different projects.

The flag “work in progress” is set to an asset when:

1. By default when an asset is created

2. When an asset is added as a target collection to a project seeking assets or is added to an improvement project

The flag “work in progress” is removed when:

1. The asset is published for consumption

2. The asset is created or added as a target collection to a project and the project is moved to “Seek assets” stage from “Define Scope and Schedule” stage

Deletion of a collection folder and collection

The folder in a collection hierarchy cannot be deleted if the collection is a target collection in any open project.

If a collection is a target collection in any open project, the collection cannot be deleted.