Process-based Part Requests in Altium NEXUS

Parent page: Working with Managed Components

The number of design components available to an engineer when capturing their next design can vary from a few hundred scattered across individual symbol and model libraries, through to hundreds of thousands, stored in a dedicated company parts database. But no matter how many components are available to hand, there will always be more that aren't, and that need to be created and added for reuse.

For a small design house, an engineer will simply change 'hats' and become the Librarian - whipping up required components that are missing from their design arsenal. However, for a larger organization that employs a dedicated library department to grow and maintain the design components - accessible to all engineers and designers in that organization - it makes sense to submit requests for new (missing) components to that department. Providing an elegant solution to this, Altium NEXUS, in conjunction with your managed content server, offer the Part Requests feature.

An engineer can simply put in a request for one or more parts to be created, and get notified when that request has either been completed, and the component(s) made available, or rejected (and why). The requestor supplies as much key information to support their request as possible (manufacturer and part number(s), description(s), any relevant datasheet (PDF or URL)). Stub Component Items can even be created that the librarian can then run with (and finish off).

Part Request Process Workflows

Related pages: Creating & Managing Processes

Altium NEXUS provides a powerful collaborative design environment. Part of that is the support for Workflows, that guide a company's designers through typical, everyday design processes such as the creation of new managed parts. Each Workflow that is used to implement a particular design process is created as part of a Process Definition. It can therefore be referred to as that process's underlying Workflow, or simply a Process Workflow.

Processes, and their Workflows, are created and managed through the managed content server's browser-based interface - by an Administrator of that Server. Three predefined process workflows are defined for Part Requests out-of-the-box:

• New Part Request - activated by default, not removable, and the workflow diagram for which is shown below.

• New Part Request Assign - activated by default, not removable, and the workflow diagram for which is shown below.

• New Part Request Multiple Tasks - not activated by default, is removable, and the workflow diagram for which is shown below.

These can be found on the Part Requests tab of the Processes page of the browser interface. Use these, modify them, or create your own as required - a powerful Process Workflow Editor provides the flexibility for you to build processes with workflows that can be as simple, or as complex as needed, and in-line with your company's requirements.

Initiating Part Requests

Once the required set of process definitions for the Part Requests process theme are crafted as required for your company, those definitions that are activated will be available for use by all users once they are signed into the managed content server. The following sections take a look at where a designer can access, and start these active processes - both through Altium NEXUS, as well as the managed content server's browser interface.

Administrators for the managed content server can start a new instance of any activated process definition - directly from the Part Requests tab within the Processes area of the managed content server's browser interface - by clicking the  control.

From within Altium NEXUS

From within Altium NEXUS, activated process definitions that are part of the Part Requests theme can be accessed in two places:

• From the Explorer panel, after having conducted a search.

• From within the Part Search panel, with a search item selected.

In both cases, the  button, when pressed, will present the active part request process definitions available to choose from.

If no active process definitions are available for the Part Requests process theme, the  button will not be shown. You may need to sign out of the managed content server, and back in again to refresh.

Starting a Request

After choosing the required part request process definition, the Start Part Request dialog will appear. This will present controls for defining the requested part - supply as much information as possible so that the person assigned to make the component can deliver the part exactly as needed.

The actual information contained in the dialog will depend on the content defined in the associated form for the Start element of the process workflow. The following image shows the form defined for the Start element of the New Part Request process definition, along with the resulting Start Part Request dialog when that definition is run from the Explorer panel.

Example showing the Start Part Request dialog when running the New Part Request process definition, from within the Explorer panel. The content of the dialog is determined
to a great extent from the underlying form for the Start element of that definition's process workflow.

The following image shows the Start Part Request dialog when the New Part Request process definition is run from the Part Search panel. Submitting a part request from this panel has the added benefit that it will auto-fill key information for you, including all data sheets and parametric information.

Example showing the Start Part Request dialog when running the New Part Request process definition, from within the Part Search panel. Notice that a lot of information is
pre-filled for you (highlighted in green for the part chosen here).

For the default part request process definitions, the following controls are available:

• Request title - a title is automatically generated with, and assigned to, the request, in the format <ProcessName> #n. This field contains the text AUTO and is non-editable.
• Part number - this is a mandatory field indicating to the librarian the specific part number of the part you need them to make.
• Manufacturer - this is a mandatory field to indicate to the librarian who actually makes the part.
• Description - this field can be used to give a rich description of the part (typically taken from the manufacturer datasheet).
• Priority - this is a mandatory field used to indicate the priority of the request. Choose either Low, Medium, or High.
• Needed by - use this field to specify the date by which you need the component to be ready. Clicking within the field will pop-up a calendar window, with which to specify the required date.
• Link - if you have a URL for the part's datasheet, enter it into this field.
• Datasheets - if you have any datasheets available for the part, add them using this field, either through a dialog by clicking the  button, or by dragging and dropping them onto the indicated area. Files of any format can be attached, without limitation. To remove a file, click on its remove control ().
• Preliminary components - use this field to add links to existing Symbol, Footprint, and Component Items in your managed content server, and which can be used as a basis for creation of the requested part. Click in the field and start typing to access a list of available Items (by Item ID). Choosing an entry will add it to the field. To remove an entry, click on its close control ().

Add links to existing Items in the managed content server, which can be used when creating the requested part.

• Properties - this field is only available when starting the request from a chosen part in the Part Search panel and simply loads/presents the parameters for that part, along with their values.

With all data entered/specified as required, click the  button to initiate the request. The Part number, Manufacturer, and Priority fields are the bare minimum pieces of data that are required for a part request to be processed, and hence they are mandatory fields. If you try to start the request without one of these fields defined, the field will be flagged as required, presented with a red background, and the  button made unavailable.

The Part number, Manufacturer and Priority are essential pieces of information needed to create the new part and, as such, are
mandatory - you cannot proceed with the request while one of these remains undefined.

From the Browser Interface of the Server

From the managed content server's browser interface, activated process definitions that are part of the Part Requests theme can be accessed from the Part Requests page, by clicking the  button at the top-right of the page.

Accessing activated Part Requests definitions from the Part Requests page of a managed content server's browser interface.

If no active process definitions are available for the Part Requests process theme, the  button will be unavailable. If only one process definition exists, the button will not appear with drop-down functionality, and will start that process immediately upon being clicked.

Starting the Request

After choosing the required part request process definition, a pop-up window will appear, whose title reflects the name of the chosen process definition. This will present controls for defining the requested part - supply as much information as possible so that the person assigned to make the component can deliver the part exactly as needed.

The actual information contained in the dialog will depend on the content defined in the associated form for the Start element of the process workflow. The following image shows the form defined for the Start element of the New Part Request process definition, along with the resulting New Part Request pop-up window.

Example showing the New Part Request pop-up window when running the New Part Request process definition from within the server's browser interface. The content of
the window is determined to a great extent from the underlying form for the Start element of that definition's process workflow.

For the default part request process definitions, the following controls are available:

• Request title - a title is automatically generated with, and assigned to, the request, in the format <ProcessName> #n. This field contains the text AUTO and is non-editable.
• Part number - this is a mandatory field indicating to the librarian the specific part number of the part you need them to make.
• Manufacturer - this is a mandatory field to indicate to the librarian who actually makes the part.
• Description - this field can be used to give a rich description of the part (typically taken from the manufacturer datasheet).
• Priority - this is a mandatory field used to indicate the priority of the request. Choose either Low, Medium, or High.
• Needed by - use this field to specify the date by which you need the component to be ready. Clicking within the field will pop-up a calendar window, with which to specify the required date.
• Link - if you have a URL for the part's datasheet, enter it into this field.
• Datasheets - if you have any datasheets available for the part, add them using this field, either through a dialog by clicking the  button, or by dragging and dropping them onto the indicated area. Files of any format can be attached, without limitation. To remove a file, click on its remove control ().
• Preliminary components - use this field to add links to existing Symbol, Footprint, and Component Items in your managed content server, and which can be used as a basis for creation of the requested part. Click in the field and start typing to access a list of available Items (by Item ID). Choosing an entry will add it to the field. To remove an entry, click on its close control ().

Add links to existing Items in the managed content server, which can be used when creating the requested part.

With all data entered/specified as required, click the  button to initiate the request. The Part number, Manufacturer, and Priority fields are the bare minimum pieces of data that are required for a part request to be processed, and hence they are mandatory fields. If you try to start the request without one of these fields defined, the field will be flagged as required.

The Part number, Manufacturer and Priority are essential pieces of information needed to create the new
part and, as such, are mandatory - you cannot proceed with the request while one of these remains undefined.

Initial Request Assignment

How a new part request initially gets assigned, depends on the settings defined for Assignee and Task ownership - defined for the initial User Task encountered after request submission, as part of the process definition's underlying workflow.

• Assignee - could be a single user for your managed content server, multiple users, or a specific role (grouping of users).
• Task ownership - determines who can act on a task, in relation to the user(s) specified in the Assignee field. The following options are available:
  • One of assigned users - if there is only a single user in the Assignee field, the initial task of working on the request is assigned directly to that user. If there are multiple assignees, all users see the task in their tasklist, and one of those users assigns the task to themself.
  • All assigned users - all assignees receive the task.

For the default Part Request process definitions, the Assignee is defined to be the admins for the managed content server (members of the Administrators role). Task ownership is set to One of assigned users, meaning that one of those administrative users must take on the request.

Which user initially receives the task of working on a new part request, depends on how the settings for Assignee and Task ownership have been defined, for the initial user
task - in the underlying workflow for the applicable process definition. The image above shows the settings for the default New Part Request process definition.

Working on a Part Request

Related pages: Working with Tasks

Once a Part Request has been initiated, interaction with that request - or rather its defined process workflow - is through the concept of Tasks. A Task relates to a user task defined within the workflow - a point at which action by a user is necessary for the workflow to progress. For a Part Request, the initial task in the workflow will be directed to the person assigned to, and responsible for, creation of that part.

Accessing Tasks from within Altium NEXUS

When you are signed into your managed content server through Altium NEXUS, your current list of tasks will be available through the Tasklist panel. For Part Request related tasks, look to the Title of the task, which reflects the name of the associated process, along with an instance suffix (e.g. New Part Request #5). The task's name is simply the name given to the user task element in the process's underlying workflow.

Clicking on a task's entry will access a dialog containing the form associated to that task. The form presents all information and fields that have been defined for that specific user task - by an administrator when crafting the process workflow - in order to obtain choices, information, or data from the user, which will facilitate the onward progress of that workflow.

Example form for a user task associated with the default New Part Request process, when accessed from the Tasklist panel in Altium NEXUS.

To view the underlying workflow for the task's parent process, make the Diagram tab active. The diagram shows the complete workflow for the process, and the point that has been reached in that flow - the user task which you are currently addressing, reflected by the inclusion of your name.

Accessing the workflow diagram for the default New Part Request process, highlighting the user task requiring action, and by whom.

Interact with the form as necessary to complete your task. This could mean choosing an option, making a comment, or attaching additional files/data. For the default New Part Request process for example, the task for the creator of the part has three key fields:

• Components - use this field to add links to Symbol, Footprint, and Component Items in your managed content server, and which have been created to deliver the requested part.
• Next step - use this field to determine what happens next in the life of this part request:
  • Completed - choose this option if you have created the part (and related domain models if applicable).
  • Rejected - choose this option if you do not intend to create the part (and crucially, adding a reason why in the Note field).
  • Needs more info - choose this option if you cannot create the part at this time without further information from the requestor (and crucially, add what is needed in the Note field).
• Note - use this field to provide a comment in relation to the task. For example, indicating that the newly-created managed component is 'good to go', or a concise explanation of why the requested part will not be created. And if you require more information from the requestor, this is the place to flag what was missing from the original request!

Once you have filled in the form for your task as required click the  button, so that the process can flow to the next relevant stage. The task will be deemed complete and will be removed from the panel.

Accessing Tasks from the Browser Interface of the Server

Sign in to your managed content server's browser interface and access the Tasks page, to see a list of your currently outstanding tasks, which require action. Each task is a specific stage reached within an associated process workflow.

For Part Request related tasks, look to the Title of the task, which reflects the name of the associated process, along with an instance suffix (e.g. New Part Request #5). The task's name is simply the name given to the user task element in the process's underlying workflow.

Click on the applicable task entry - relevant to the Part Request - to have its associated form presented on the Form tab, on the right-hand side of the page. The form presents all information and fields that have been defined for that specific user task - by an administrator when crafting the process workflow - in order to obtain choices, information, or data from the user, which will facilitate the onward progress of that workflow.

Example form for a user task associated with the default New Part Request process.

To view the underlying workflow for the task's parent process, make the Diagram tab active. The diagram not only shows the complete workflow for the process, but also the point that has been reached in that flow - the user task which you are currently addressing, reflected by the inclusion of your name.

Accessing the workflow diagram for the default New Part Request process, highlighting the user task requiring action, and by whom. In this case, user
altium.si.entist@gmail.com is tasked with creating the requested part, and needs to address the task in order for the workflow to proceed to its
next event.

Interact with the form as necessary to complete your task. This could mean choosing an option, making a comment, or attaching additional files/data. For the default New Part Request process for example, the task for the creator of the part has three key fields:

• Components - use this field to add links to Symbol, Footprint, and Component Items in your managed content server, and which have been created to deliver the requested part.
• Next step - use this field to determine what happens next in the life of this part request:
  • Completed - choose this option if you have created the part (and related domain models if applicable).
  • Rejected - choose this option if you do not intend to create the part (and crucially, adding a reason why in the Note field).
  • Needs more info - choose this option if you cannot create the part at this time without further information from the requestor (and crucially, add what is needed in the Note field).
• Note - use this field to provide a comment in relation to the task. For example, indicating that the newly-created managed component is 'good to go', or a concise explanation of why the requested part will not be created. And if you require more information from the requestor, this is the place to flag what was missing from the original request!

Once you have filled in the form for your task as required, click the  button. The task will be deemed complete and will be removed from your list of tasks.

Viewing Part Requests

At any time, a user can view the part requests that they were responsible for initiating - both active requests, and closed requests. This can be done from two places.

Part Requests Page (Server Browser Interface)

From the Part Requests page of the managed content server's browser interface, you can centrally browse all part requests that you have initiated.

Access the part requests that you have initiated. If you're an adminstrator for your managed content server, you'll see all part requests, initiated by any user.

By default, the upper region of the tab presents all Active (running) part request processes. Switch to viewing all Closed processes (e.g. completed, rejected, or terminated) us ing the drop-down field above the list.

Browse all active part request processes from the one convenient location. Roll over the image to see an example of browsing all closed part request processes. Note that the
user signed in above is an administrator for the Server, and so sees all part request activity. In contrast, a standard (non-admin) user would just see the part requests they initiated.

For each entry, the following information is presented (where applicable):

• Status - the state of the part request process. This can be one of the following:
  •  Active - the part request process is currently active, and its associated workflow is progressing.
  •  On hold - the part request process is currently active, but is awaiting initial input, such as assignee allocation, before its workflow can progress.
  •  Closed - the part request process is now closed, for example was either successfully completed, or rejected.
  •  Terminated - the part request process is now closed, and was terminated directly by either the initiator of the request, or a NEXUS Server Administrator.
• Process Name - the name of the part request process definition.
• Title - this field is used to distinguish between multiple instances of the same part request process. The title is the process name, with an instance suffix (#1, #2, and so on).
• State - this is the state currently reached within the process's associated workflow.
• Assignee (Active process only) - this is the user who now has a task to perform to move the part request process along from its current workflow state.
• Started By - the user who initiated the part request process.
• Started At - the date and time at which the part request process was started.

For an active part request process, there is also a Terminate control (). Click this to force-end a part request process. The process will move to the Closed listing of part request processes. Only the initiator of a part request, or a member of the Administrators role for the Server, can terminate a part request process.

Part request processes can be sorted by any column possessing the  control - click on the control, or the column name. Searching can also be conducted, using the Search field at the top of the list. Data in all fields except Status, Started At and Terminate can be used to search.

Click on an entry for a part request process to view a diagram of its underlying workflow (on the Diagram tab below the list), showing what needs to happen for the process to be completed, and where that process is at along its flow, in terms of who now has a task to perform to move the process along.

Click the  control at the bottom-right to highlight the current point reached in the workflow - the user(s) entry will flash momentarily.

Viewing the underlying workflow for a selected part request process on its Diagram tab. Each workflow is built diagrammatically allowing you to see at-a-glance where in the
workflow a part request currently sits, and who now has the next task in order to continue progress of that request.

The following additional tabs are also available:

• Data - showing all pertinent data for the process. For a part request process, this can include attached datasheets, parametric data, and any preliminary components.

• History - showing a history of actions taken along the process's workflow.

Use the Data and History tabs to browse more detail for the part request process, and a trail of its workflow activity, respectively.

Tasklist Panel (Altium NEXUS)

When you are signed into your managed content server through Altium NEXUS, all process-based activities that you have initiated will be available to browse in the Activities region of the Tasklist panel. To list only Part Request processes, click the  button, and disable the Project Activity and Project Creation entries (leaving only the Part Request entry enabled).

Access the part requests that you have initiated, directly from within Altium NEXUS.

By default, the region presents all Active (running) part request processes. Switch to viewing all Closed processes (e.g. completed, rejected, or terminated) by clicking the  button, and enabling the Show closed entry.

For each entry, the following information is presented (where applicable):

• State - the state of the part request process. This can be one of the following:
  •  Active - the part request process is currently active, and its associated workflow is progressing.
  •  On hold - the part request process is currently active, but is awaiting initial input, such as assignee allocation, before its workflow can progress.
  •  Closed - the part request process is now closed, for example was either successfully completed, or rejected.
  •  Terminated - the part request process is now closed, and was terminated directly by either the initiator of the request, or a NEXUS Server Administrator.
• Type - the name of the part request process definition.
• Title - this field is used to distinguish between multiple instances of the same part request process. The title is the process name, with an instance suffix (#1, #2, and so on).
• Started - the date and time at which the part request process was started.

Clicking on an entry will access a dialog presenting the underlying workflow for the task's parent process - on that dialog's Diagram tab - showing what needs to happen for the process to be completed, and where that proc ess is at along its flow, in terms of who now has a task to perform to move the process along. Switch to the dialog's Data tab to show all pertinent data for the process. For a part request process, this can include attached datasheets, parametric data, and any preliminary components.

Viewing the underlying workflow for a selected part request process on its Diagram tab. Each workflow is built diagrammatically allowing you to see at-a-glance where in the
workflow a part request currently sits, and who now has the next task in order to continue progress of that request. Switch to the Data tab to see attachments for the request.

Notifications

Only the original requestor and any user required to perform a task relating to that request, will receive applicable notifications. The requestor, who initiated the request, receives notification when that new part request has been submitted and also when it is completed (either the part has successfully been created, or the request has been rejected). A user working on the request will receive notification of any task relating to that request, and that requires their attention. This could be the original requestor, if more information is required from them.

Notifications will be received in a user's message stream, on the Stream page of the managed content server's browser interface (and summarized on the Home page of the interface).

Example notifications in action - user altiumdesigner313 initates a new part request and receives notification of having done so, while assigned user alitum.si.entist
receives a notification that they have a task to work on that request.