Managing item documents

00:05

In this video, we will check out a document from an item to make changes, check the document back in to commit those changes,

00:12

and send a document through a workflow to be published.

00:16

Let's take a look.

00:21

In the previous lesson, you learned how to upload a document to an item.

00:26

At this stage, you should have one document uploaded to either a document category or a specification type.

00:34

And it should still be in a draft state.

00:39

The item that it belongs to should still be in development at this stage as well.

00:45

Now, let's explore what we can do with this document.

00:49

When it was first uploaded, it was not in a finished state.

00:52

However, I wanted to store it in Upchain, so that all changes could be managed there.

00:58

And, by having it in one place, I could get some feedback from my colleagues as well.

01:03

And, depending on the purpose of the document, you might need it uploaded to an item as soon as possible,

01:09

so that the designers can use it as a reference right away.

01:15

To make changes to a document, it must be checked out.

01:18

To do this, click the action menu beside the document, and select "check out".

01:25

Decide on a location on your computer to save the document and click "save".

01:38

This now locks the document to you so that no other users can make changes to it while you are working on it.

01:47

And the document is saved to your chosen location on your computer,

01:52

and that is where all changes are saved until you are ready to upload it back into Upchain.

02:01

Be careful.

02:02

If you have checked out this document before and the file still exists in the same location on your computer,

02:09

Windows will add numbers in brackets to the file name to prevent overriding previous copies of this document.

02:18

But if you were to save the file with this altered name, this will not match the name as it is known in Upchain.

02:27

So you won't be able to upload this file back into Upchain when it's time to check it back in again.

02:35

So, always ensure the file, when it's downloaded, retains its given Upchain name.

02:47

Once you've made some changes to your documents, you must commit those changes back into Upchain,

02:53

so that the changes can be tracked there and so that other users are able to view the changes that you've made.

02:59

Currently, all your changes are still on your local computer.

03:04

To check in a document, click the action menu beside the document to be checked in, and select "Check in".

03:14

In the window that opens, click the "Select Document" button.

03:20

Locate the document on your computer that you have made changes to.

03:25

And click "Open".

03:28

Upchain detects that changes have been made to the document.

03:33

If it detects no changes were made,

03:35

it will not let you check in the same unchanged document to prevent you from creating new document versions unnecessarily.

03:44

Type in a change description, so that other users know what changes you've made and click "done".

03:57

This now uploads a copy of the document into Upchain and it creates a new file version.

04:07

You can repeat this process of checking out the document, making changes,

04:11

and checking back in as many times as necessary until the document is considered finished.

04:18

It is useful to check-in regularly to commit incremental changes.

04:25

In our example, let's assume the document is now in a finished state.

04:29

We should publish it so that other users know it has been finalized and signed off.

04:35

You should publish all documents within an item before the item is released.

04:41

This is because, for all specification types, and by default for all document categories,

04:49

once an item is released, the documents inside it cannot be changed.

04:57

You can set certain document categories to be editable on released items.

05:01

But generally, once an item is released, the entire item becomes read-only.

05:08

We'll discuss this further in a later video.

05:12

To move the document to a published state, it must be assigned a workflow that contains a step to publish the document.

05:19

To set the workflow, click the "Action" menu and open the document's Details view.

05:26

Click the "Pencil" icon to edit its details.

05:30

Select your desired workflow from the drop-down menu.

05:34

In our example, we are just going to use the workflow provided to all tenants.

05:40

Click "Save".

05:45

A button to begin the workflow now appears at the top of the Details view.

05:50

Click this button to begin the workflow.

06:03

This is the workflow provided to all tenants and its first step is to move the document to a status of "In Review",

06:11

and it sends a task to the project manager to review the document and either approve or reject the request for publishing.

06:24

So everything that we've demonstrated so far in this video, checking out, checking in,

06:29

and sending a document to a publishing workflow is the same for all documents in all of your document categories,

06:37

as well as any in your custom specification types.

06:43

This should give you a good understanding of how to check out a document to make changes,

06:49

how to check it back in to commit those changes, and how to set a workflow to initiate the publishing process.

06:57

Keep going to learn more.

00:05

In this video,

00:06

we will view a compatible document in the PDF viewer

00:09

and gain some familiarity with its functionality,

00:13

explore what happens when the publishing workflow is rejected,

00:17

and complete the publishing workflow to publish a document.

00:21

So let's take a look.

00:26

I am logged in as the project manager for this project.

00:31

And I can see

00:32

that this document is awaiting review.

00:40

If I have a look at its details,

00:43

the buttons to approve or reject

00:46

are enabled for me.

00:50

I have also received an email notification

00:54

indicating that there is a document to be reviewed.

00:57

However,

00:58

clicking the link in this email does not take you to the item the document belongs to.

01:04

Instead,

01:04

it takes you to the document section of the project.

01:09

So,

01:09

if you are unsure where to find this document,

01:13

you can perform a quick search for it.

01:17

And then clicking on the document from the search results

01:21

will take you to the item that it belongs to.

01:25

Again,

01:26

the user role doesn't matter when working with documents,

01:29

just that the user has the correct license.

01:32

The role

01:33

only comes into play when dealing with workflows,

01:37

as it is often a specific role that is called out to perform different tasks.

01:43

In the case of our document approval workflow,

01:46

it is the person with the project manager role on the project

01:50

who is in charge of reviewing this document.

01:53

And deciding whether to publish it or not.

02:01

While you can upload files of practically any type into Upchain,

02:04

only certain file types are compatible

02:07

with the PDF viewer.

02:10

Look in the help documentation for a full list of compatible file types.

02:16

We have uploaded the requirements documents

02:18

as a Word document,

02:21

and this is compatible with the viewer.

02:24

For someone who wishes to review the document without having to download it

02:29

and open it in its native program,

02:31

you can instead use the PDF viewer

02:34

to view that document directly in the web application.

02:38

To open the document in the viewer,

02:39

click the Action menu beside the document

02:42

and select open PDF web viewer.

02:45

You'll only see this option for files

02:47

that are compatible.

02:51

We will not spend a long time on the PDF viewer.

02:54

You can find more information on all

02:56

of its functionality in the help documentation.

03:00

But to give a brief overview,

03:04

there are several actions you can take.

03:06

You can annotate the document

03:08

with a variety of texts,

03:10

comments,

03:12

shapes,

03:13

and if you're viewing a drawing,

03:15

you can also measure

03:18

various aspects of that drawing as well.

03:26

Here,

03:27

I would like to point out

03:29

that

03:31

the version

03:33

is not in the right format.

03:41

I'm also going to add a comment here

03:44

to say that we are missing a section on reporting requirements.

03:53

So,

03:54

as you can see,

03:54

there are a variety of tools you can use to

03:57

describe what needs to be changed in the documents.

04:03

You can also save your annotations as a markup.

04:12

This means

04:13

that others

04:14

who also open this document are able to view these

04:17

markups and load more than one at the same time.

04:24

You are also able to download a copy of this PDF with its annotations from this menu,

04:32

or you can download a blank copy without the markups

04:36

from this button here.

04:38

To communicate the changes that need to be made,

04:41

you have several options.

04:43

We're not going to go into depth on those here,

04:46

but to give you an idea,

04:47

you could download the document with its markups

04:50

and attach it to an investigation request,

04:53

a project task,

04:55

or an email and send those off to the appropriate recipients

04:59

with sufficient information so that they understand what they need to do.

05:03

And again,

05:04

review the help documentation for more information

05:07

on the tools available in the PDF viewer

05:09

and options for tracking work in Upchain.

05:13

Now,

05:14

because changes are needed,

05:16

the document is not ready to be published,

05:18

so I will reject the workflow.

05:29

Now,

05:30

sometimes you may need to refresh the item details pane,

05:35

to be able to see the correct status updated beside the document.

05:46

And there it is there.

05:47

The document is back in a draft state,

05:49

still at version 3,

05:51

no revision level yet.

05:58

Logged back in as the mechanical manager

06:00

in charge of this document,

06:02

I can see that the document is back in a draft state,

06:07

even though we submitted it to a workflow,

06:10

so that tells me it has been rejected.

06:15

I have also received

06:18

an email

06:19

indicating that the published was declined.

06:28

I could now open the document into the PDF viewer,

06:32

and review the markup that was made as indicated to me by my

06:36

project manager, in whatever format they

06:37

chose to communicate the required changes.

06:47

Now,

06:48

since I need to make changes to this document,

06:54

I can

06:55

do that by checking it out,

06:59

downloading it to my computer

07:01

to make the appropriate changes.

07:13

And once those changes are made,

07:15

I need to check the document back in to commit those

07:18

changes into Upchain and create a new version of the document.

07:23

I could check out and check back in as many times as necessary.

07:30

Note that we would only be able to do this

07:33

while the item was still in development.

07:36

If the item was already released,

07:38

the document would be locked at the version it was at.

07:42

You would need to revise the item to put it back into development

07:46

to be able to work on that document.

07:48

This is always true

07:50

for documents in the custom specification types.

07:58

The exception to this is if the document category the document

08:01

is in has been set to be editable on released items.

08:06

You could then proceed as outlined above,

08:08

regardless of the item status,

08:10

but by default,

08:11

all document categories

08:14

cannot be edited on released items.

08:16

So in general,

08:17

it is best to ensure all of your documents are published

08:21

before the item is released.

08:29

Now that we're dealing with a new document version,

08:33

we must submit this new version to the publishing workflow once more.

08:40

So this back and forth between teammates

08:43

over publishing and reviewing the document could continue

08:46

for a number of different document versions.

08:55

Again,

08:55

logged in as the project manager,

08:57

assuming the changes made have been accepted this time,

09:02

the document

09:02

can be moved to a published state.

09:17

Again,

09:18

let's refresh the item detail view here by clicking away and clicking back again.

09:27

And we can see that the document is published at version 3,

09:31

and the revision level has been set to AA

09:35

in our case.

09:39

If the document requires further changes,

09:42

it must be revised.

09:43

This can be done by simply checking out the published documents,

09:47

making changes,

09:47

and checking it back in.

09:49

The first time it is checked back in,

09:52

a new document version is created and put back into a draft state.

09:57

Again,

09:58

you can only revise the documents if the item is in development

10:02

or it exists in a document category that is editable on a release item.

10:15

If a document is somewhat relevant to another item,

10:19

you can clone it

10:21

to make a new copy of it and paste it into a different item.

10:26

This creates a copy of that document with a new

10:29

number and means you wouldn't be starting from scratch.

10:34

You can also archive a document if you wish to keep it in the item as a reference,

10:40

but essentially label it as no longer in use.

10:43

More about these functions are covered in the document management 2 course.

10:50

This should give you a general understanding

10:52

of the PDF viewer and its functionality

10:55

using a workflow to publish a document,

10:58

what happens when the workflow is both rejected and accepted,

11:03

and how a document's life cycle relates to the item's life cycle.

11:07

Keep going to learn more.

00:04

In this video, we will explore how a document behaves inside a released item,

00:09

and explore when it is possible to edit a document inside a released item.

00:15

So let's take a look.

00:19

An item in development means everything related to that item, including attributes, CAD models, drawings,

00:27

supporting documentation and so on, can be modified.

00:31

Once an item is released, this effectively makes the entire item read-only,

00:37

including the documents in its document categories and specification types.

00:44

In other words, the documents in a released item cannot be checked out, only downloaded and viewed.

00:58

However, there is a setting that a tenant administrator can set to make a document category editable on a released item.

01:07

In our example, you'll notice that all document categories and specification types no longer have an action menu beside them,

01:17

except for the Quotes category.

01:20

This is because it has been set to be editable on a released item, so that once the item is finalized,

01:27

we can still upload and manage quotes related to the item within this category.

01:34

This setting is not available for specification types.

01:38

These categories will always become read-only once the item is released.

01:45

So let's explore what we can do with documents in different stages of their publishing process once the item is released.

01:53

The first document here is already published, which is good.

01:58

And the actions we can take on it are simply to view and download it.

02:02

So we are unable to revise that published document.

02:09

In this document category, the project plan is still in draft.

02:14

We are able to view its details, and we can set and start a workflow.

02:33

However, if we were to reject this workflow at document Version 3, the document would be put back into a draft state,

02:56

as we can see here.

02:60

And we would not be able to check out this document and check it back in to make a new version.

03:07

We have used up our attempt to publish the document at Version 3, and there is no possibility to increment that version.

03:21

This is true of any documents in our custom specification types as well.

03:33

We are unable to check them out to make new versions,

03:37

so we would need to ensure that any documents in these specification types are published in these categories before the item is released.

03:52

Now let's look at the quotes category here.

03:56

Beside the category, we still have the option to add folders and documents.

04:03

The document inside it is still in a draft state, and you can see we have access to the full action menu to check out the document,

04:12

check it back in, view its details and set a workflow, so we can manage it as if the item was still in development.

04:25

What have we learned?

04:27

Documents should be fully published within an item before it is released.

04:33

Otherwise, you run the risk of having documents stuck in limbo, like we saw for the project plan document.

04:41

It is now stuck in draft at Version 3.

04:45

You'd have to revise the item to be able to work on that document further.

04:52

In general, the item would need to be revised to return it to a development state,

04:57

if any further document changes were needed to the specification types,

05:02

or documents in any of the non-editable document categories,

05:08

so consider carefully the order in which you need to manage your documents associated with items in relation to the lifecycle of the item itself.

05:18

Consider what document categories you may still need to edit after an item is released.

05:25

But remember, you can only do this for document categories, not specification types.

05:31

So you might consider including a step in your change request workflow,

05:37

to have someone ensure the documents are published in the items before the item can be released.

05:45

And if not, they should be able to cancel that workflow.

05:50

Also, in relation to the item lifecycle, if the item is cloned from the mechanical CAD plugin,

05:57

this will also clone the documents inside it and assign them all a new number.

06:04

You should now have a better understanding of how the document lifecycle relates to an item's lifecycle,

06:11

and when it is possible to edit a document in a released item.

06:16

Keep going to learn more.