How to trigger Power Automate during debug, test and production stage, to prevent infinite loop, with SharePoint item events

Some post recommends to set up a extra column to apply the control. It definitely works, but it needs extra column and extra actions.

Here is something much easier.

1. Define at least three dedicated user accounts

For example, tester1@company.com, developer1@company.com, PowerAutomateService@company.com

The first two accounts are for tester and developer. Power Automate runs under PowerAutomateService@company.com.

2. Change the settings of the trigger conditions

During debugging:

@equals(triggerOutputs()?['body/Editor/Email'],'developer1@company.com')

During testing:

@equals(triggerOutputs()?['body/Editor/Email'],'tester1@company.com')

During production:

@not(equals(triggerOutputs()?['body/Editor/Email'],'PowerAutomateService@company.com'))

PS: It needs three extra user subscriptions in this case, but hopefully our company doesn't mind.

Office 365 is too complicated!

At the moment, I can see 23 Apps under Office 365.

How can we train thousands of users to understand when to use which one?

In my opinion, we only need three apps, and Dynamics 365 should not be part of Office 365.

1. Synchronous communication: Online chatting service(Teams)
2. Asynchronous communication: Email(Outlook)
3. Information management: SharePoint

Most of those apps should join SharePoint. They are:

Calendar,Delve, Excel, Flow, Forms, OneDrive, OneNote, People, Planner, PowerBI, PowerApps, PowerPoint, Stream, Sway, Tasks, To-Do, Video, Word, Yammer

So, why it is so complicated? For more subscription fees?

https://www.office.com/apps?auth=2&home=1

Microsoft Flow - Send Email - You don’t have permissions to send emails on behalf of . Contact to check shared mailbox permissions and gain access.

When sending email from Microsoft Flow, I got the error below:

"You don’t have permissions to send emails on behalf of . Contact  to check shared mailbox permissions and gain access."


Click "Send an email" action and get the detailed error message:

"You are not authorized to send mail on behalf of the specified sending account."


Some people suggests, For the Shared Mailbox, you just need to make sure that you or whoever/whatever account will execute the flow will have Send As permissions to it. Then just set the From parameter of the function to the email address of the shared mailbox

It may work. But the easier option is to leave "From (Send as)" field blank.

PowerApps - save list item into list folder

We know that PowerApps doesn't support folder in SharePoint list. And Workflow 2013 doesn't support it either. As they are both triggered from remote PowerApps or Workflow server, I believe they both use REST API to communicate with SharePoint Online. And the REST API does not have complete support for folders.

So we have to use workflow to "move" the saved item into folder.

Lucky Workflow 2010 is still there, so we can use it to create list item in folder. However, we cannot create a list item from workflow 2010 instance, if the workflow is triggered by item creation.

The only choice is List Workflow 2013 + Site Workflow 2010.

When item is saved into list root folder by PowerApps form, it triggers the list workflow 2013 instance, which change the primary key field (to avoid the conflict with the forthcoming new item in the folder), then start the site workflow 2010 instance.



Pass ItemId to the site workflow parameter list.

In the site workflow, check to create folder if necessary, then create the item in the folder (specify folder name in the folder field), then delete the original item in the root folder.

The List Workflow 2013 instance will not be triggered if the item is created by workflow 2010 instance.

All these steps will be executed in less than 30 seconds during my test, so users need a little bit patience to see the result in the relevant folder.

Done.

Resolved - PowerShell script only works in Console, but not in ISE?

I'd like to collect workflow information from SPO. But the script below only works in Console, not in ISE.

$WfServicesManager = New-Object Microsoft.SharePoint.Client.WorkflowServices.WorkflowServicesManager($ctx,$Web)

The error message: Cannot find an overload for "WorkflowServicesManager" and the argument count: "2"

Below is how I did the trouble shooting.

1. Compare the PowerShell environment version information.

$PSVersionTable shows everything is same in Console and ISE.

2. Make sure the class exist in both environment.

$ClassName = "Microsoft.SharePoint.Client.WorkflowServices.WorkflowServicesManager"
if ($ClassName -as [type]) {
"$ClassName is already loaded"
}
else{
"$ClassName is not loaded"
}

Yes, the class is loaded.

3. Check how many relevant assemblies are loaded.

[appdomain]::currentdomain.getassemblies() | ?{$_.CodeBase -match "WorkflowServices"}

Here I noticed that ISE loaded a PnP assembly which also contains "Microsoft.SharePoint.Client.WorkflowServices.WorkflowServicesManager"

Obviously this is the root cause.

I think this is caused by old version PnP, so just removed/uninstalled these assemblies first.

Uninstall-Module SharePointPnPPowerShellOnline -AllVersions -Confirm

Then reinstalled the latest version.

Done.

The way to debug workflow 2013 from SharePoint Online

Thanks for the post from Andrew Connell, we got basic concept of workflow 2013 debugging.

As more and more enterprises migrating their SharePoint to Office 365, we cannot rely on "workflow history list" on debugging.

What's the solution?

So far, the only choice is "replication". Replicating the Online Site collection to On-Premise Dev environment, then test it there through Fiddler.

As Andrew Connell mentioned, we need to build the On-Premise Dev environment carefully, but it's possible to replicate the whole site through third-party migration tool, such as ShareGate, then debug from there.

ShareGate is still expensive (although it's possible the cheapest one comparing to other competent). But it should be all right for medium to large enterprise. It's not such a big number comparing to Office 365 subscription fee of the whole company, anyway.

The confusion when a user just moved from Shared Folder to SharePoint

Traditionally, how a user write a document?

1. Launch a MS Office Program, such as MS Word;
2. Give the document a topic;
3. Put content into it;
4. Save.

The problem with SharePoint is the 4th step: "Save". "How can I save the document to SharePoint?" This is one of the most common questions.

One option is to map a SharePoint document library to local network mapped folder:

For SharePoint On-Premise:

For SharePoint Online:

Then users can save the document to that Shared Drive directly, just like what they did with "Shared Folder".

That works, but then we lost most of the benefit from SharePoint.

"SharePoint" means team work. So if a user wants to write a document, below are the steps.

1. Ask themselves the question: Where should I store this document, so other users can find it easily?
2. Who should have rights to view it, and who should be able to modify it?
3. What kind of metadata should this document has? So users can get the basic information without opening it, such as "due date, document owner, project name, etc.".
4. Go to the SharePoint document library in web browser (IE 11 is recommended at the moment), then click "new" button.

If we want to get thousands of documents to be organised well, please think about the document management (as a team) with each of the documents.

SharePoint cannot do that by itself.

PS: Thanks for the reminding from my colleague Andrew Warland, nowadays, users can save the document to SharePoint sites with the help from the latest MS Office. That saves a lot of trouble.

It's still better to think more for other team members at the very beginning.

How to get SharePoint Online access authentication for third-party tools, such as Postman or Fiddler

Third-party tools need "token"(OAuth 2.0) to get authenticated. And the token is generated based on "Client Id" and "Client Secret (key)". We can do this either manually (Postman or Fiddler), or programmatically (C#, JavaScript, etc.). This is how our cloud based application to run across different cloud platforms.

You can get more details of SharePoint OAuth 2.0 here.

For SharePoint Online, we have two options to get the token, that depends on what type of admin rights we have and what we need.

There are already some pretty good posts tell us how to do it. However, I found some description is confusing, especially about the naming of some parameters. So, I try to explain it here, based on my understanding.

The GUIDs and Keys in the sample code below are all generated randomly.

• In tenant scope (need Tenant, Global or AAD admin rights)

We can follow this post. It contains 6 steps.

====== 1. Register app ======

Go to azure portal site through web browser:
https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps

Display name: PostMan
Application type: Web app / API
Home page (Sign-on URL): https://www.getpostman.com/oauth2/callback
Application ID (Client ID of PostMan, auto-generated): 7f925812-d466-4c46-8737-0fcc1e172a98
Object ID (not used, auto-generated): 864dc037-153d-4097-8105-0454bf3042fd
Managed application in local directory



====== 2. Set permissions ======

Go to the settings of this app, then click "required permission"

Set permissions as needed, such as:
Office 365 SharePoint Online -> Delegated permissions -> Read items in all site collections

====== 3. Generate Key (Client Secret) ======

test, 27/06/2020, abcd/efghijklmnopqrstuv4yWLFWswZJGHlm9UFDp0cU=

Copy the key to a safe place. This key will be used to get the token.

====== 4. Access SPO through restful API ======

Launch PostMan,

https://<company name>.sharepoint.com/sites/test2/_api/web/lists

Get

Headers
Key             Syntax                             Value
Accept         application/json; odata=verbose    application/json; odata=verbose

====== 5. Get the Oauth 2.0 Bearer Token ======

Get New Access Token

Callback URL: https://www.getpostman.com/oauth2/callback
Auth URL : https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fkenowau.sharepoint.com
Access Token URL : https://login.microsoftonline.com/common/oauth2/token
Client ID : 7f925812-d466-4c46-8737-0fcc1e172a98
Client Secret (Key) : abcd/efgsdksFME6u4yWLFWswZJGHlm9asdfasdflk=
Grant Type : Authorization Code

Click "Request Token" button.

Access Token:
dfasdfferqergfasdfasdfasdfhbGciOiJSUzI1NiIsIng1dCI6IlRpb0d5d3dsaHZkRmJYWjgxM1dwUGF5OUFsVSIsImtpZCI6IlRpb0d5d3dsaHZkRmJYWjgxM1dwUGF5OUFsVSJ9.eyJhdWQiOiJodHRwczovL2tlbm93YXUuc2hhcmVwb2ludC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9kNjU3MGM0NC1jMGY0LTQ1MzMtOGQzZC02NTdhOGFjODBlMTQvIiwiaWF0IjoxNTMwMDczMDc3LCJuYmYiOjE1MzAwNzMwNzcsImV4cCI6MTUzMDA3Njk3NywiYWNyIjoiMSIsImFpbyI6IkFTUUEyLzhIQUFBQUh4c2JkOWE5NHYxdEYwZklRWmlVNGxRczdEeWxKN29JZmZmSGNVWGNwRVk9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJQb3N0TWFuIiwiYXBwaWQiOiIzOTE4MmRhYi1iMjI4LTQ0ZTEtODhjYS1kNmM2NGY5MGNlNjYiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6IkZhbmciLCJnaXZlbl9uYW1lIjoiRXJpYyIsImlwYWRkciI6IjIzLjEwMS4yMTcuMTU0IiwibmFtZSI6IkVyaWMgRmFuZyIsIm9pZCI6IjY0Y2ZlMzJhLTMxYzAtNDI5MC04MjQ5LTljMjY1MjI0NjBlZiIsInB1aWQiOiIxMDAzM0ZGRkFDMEMxOTdEIiwic2NwIjoiQWxsU2l0ZXMuRnVsbENvbnRyb2wgQWxsU2l0ZXMuTWFuYWdlIEFsbFNpdGVzLlJlYWQgQWxsU2l0ZXMuV3JpdGUgTXlGaWxlcy5SZWFkIE15RmlsZXMuV3JpdGUgU2l0ZXMuU2VhcmNoLkFsbCBUZXJtU3RvcmUuUmVhZC5BbGwgVGVybVN0b3JlLlJlYWRXcml0ZS5BbGwgVXNlci5SZWFkLkFsbCBVc2VyLlJlYWRXcml0ZS5BbGwiLCJzdWIiOiJPNkZtZVNnVk1ieUxXcUUtVVFhLUNxRUdxZ0ZOZW9adrwevzvzxcvcvzxVlX25hbWUiOiJlcmljZmFuZ0BrZW5vd2F1Lm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6ImVyaWNmYW5nQGtlbm93YXUub25taWNyb3NvZnQuY29tIiwidXRpIjoibzY1WFZNOG53MGlWTFZxZnNvRU9BQSIsInZlciI6IjEuMCJ9.LjxUSSWnsMTzk1Mj4Y5xn2X9Q4arUxb1Tp1FDvQqckOYIlLhg8WPg0LcAOvQVBiTA3U9IkedpXaqfre6rvycj8OZI7a6UY3YUoppJMyZ9VmmvDuDHZVIawwIk61XBQGzfVrbRu5w9BJzrbTwJCw-zlGWxbtnx_Acvz1D8kPmsWKNP7OUCVjB9hlqdBx-wAwofKxNRuJRKzIcixHhwBAveNs9MoAvn-hQ3qLIuckkW6zyjhFAqo7C_n-3Gsu_ajvin0uIbEK2G_I3SqtEMOBa9ZMdCC4aq9Mlu9AADnBYMua_29-f5SoBXy1OIfjEasdfwer35asefyuksyhtBBkW1Chog

Click "Use Token"

====== 6. Get the Response Body ======

Click "Send" button. Done.

• In site collection scope (need SharePoint or Site Collection admin rights)

We can follow this post. It contains 5 steps. (I choose an alternative way in step 3)

====== 1. Register app ======

Go to SPO site through web browser:

https://<company name>.SharePoint.com/sites/test1/_layouts/15/appregnew.aspx

The app identifier has been successfully created.

Client Id:  71b53e1e-6260-4a8d-8423-8ca65439271a

Client Secret:  SbyJ/JghRiadfdasfadsLFWswZJGHlm9UFDp0cU=

Title:  postman

App Domain:  localhost

Redirect URI:  https://localhost

Copy the Client Secret (key) to a safe place. This key will be used to get the token.

Click "OK"

====== 2. Grant permission to this App ======

https://<company name>.SharePoint.com/sites/test1/_layouts/15/appinv.aspx

Read-Only rights of the sub site:

 <AppPermissionRequests AllowAppOnlyPolicy="true">
    <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="Read" />
</AppPermissionRequests>

Full-Control rights of the whole site collection:

<AppPermissionRequests AllowAppOnlyPolicy="true">

    <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

</AppPermissionRequests>

====== 3. Get SPO Tenant GUID, resource GUID and client GUID ======

Instead of PostMan, it's much easier to get the information from this page: https://<company name>.sharepoint.com/sites/test1/_layouts/appprincipals.aspx

The app identifier syntax is: i:0i.t|ms.sp.ext|AppGUID@TenantGUID

"resource GUID" means the app GUID of SharePoint Online itself, which is: 00000003-0000-0ff1-ce00-000000000000

====== 4. Get Bearer token ======

Launch PostMan, 

https://accounts.accesscontrol.windows.net//tokens/OAuth/2

Post

Headers

Key                     Value

Content-Type application/x-www-form-urlencoded

Body

Key                     Value

grant_type           client_credentials

client_id              <ClientID>@<TenantID>

client_secret        SbyJ/JghRiadfdasfadsLFWswZJGHlm9UFDp0cU=

resource               00000003-0000-0ff1-ce00-000000000000/<company name>.sharepoint.com@<TenantGUID>

Click "Send". Copy "access_token" to a safe place.

====== 5. Access SPO through restful API ======

Launch PostMan,

https://<company name>.sharepoint.com/sites/test2/_api/web/lists

Get

Headers
Key                               Value
Accept                       application/json;odata=verbose
Authorization               Bearer

Click "Send"

Done.

The procedure is similar with C# or Javascript.

Shocking change of Office 365 and AAD licensing

Based on this post , for a company with 1000 users, to prevent users from creating Groups, Microsoft will charge AUD 91700 ( around USD 72000) per year!

So, is this the extra cost of "cloud platform"? How many of this kind of licensing changes are there waiting for us?!

I am speechless now.  :-(


[reference]

Azure Active Directory pricing
https://azure.microsoft.com/en-au/pricing/details/active-directory/

The Price of Office 365 Groups

"I honestly cannot come up with a justification for charging extra for the ability to prevent Groups from being created by every user in your organization."

https://practical365.com/blog/price-office-365-groups/

Some thoughts about Microsoft FLOW

After watching Deep dive: Advanced workflow automation with Microsoft Flow, I have to admit that FLOW is much more powerful than I thought. It can replace SharePoint workflows in most of the cases!

However, as it is designed for power users, I smelled something bad.

1. Now I start to understand that why "everyone needs to learn coding". Simple coding(or drag and drop style software development) allows users to do much more work efficiently.

2. We will get millions of worst "software programmers" to build billions of FLOW modules. These FLOW modules may run very slow, may consume a lot of hardware resource, and almost no one can maintain them. Because these FLOW modules are running in Azure, clients need to pay much higher fee than normal. (Microsoft will be very happy about that, and we cannot blame Microsoft)

3. No user would write document for the FLOW functionalities they build.

4. Fix/improve those FLOW modules is not easy, and troubleshooting on those modules would be nightmare.

5. Who is going to test the FLOW modules built by users? A module may accidentally delete a lot of data (which may not be able of recovering), or send out thousands of emails.

6. For most of the FLOW functionalities, if a developer can do it through C# in one day, he/she may need 3 days to do it through "drag and drop". And it's pretty hard to maintain those functionalities. It would take much more time to make minor changes.

7. Not sure how many security issues it will cause if we allow users to build their own FLOW modules.

8. If Microsoft decides to change/upgrade/obsolete some API/function, who is going to upgrade existing customized FLOW modules?

Conclusion: FLOW is too powerful, so it is not for power users but for developers. Normal power users can use it, but only for very simple functionality, especially when some system other than SharePoint is involved. Only in those cases, FLOW is useful to power users and can improve productivity.

Confusion and complains about Office 365

I am learning Office 365. There are many brilliant ideas in this platform, but also something annoying to me.

Below is my thoughts so far.  It will be keep updated.

[20170704]

1. Microsoft Teams really should be part of "Skype for Business", instead of a separate product.

[update 20170919] Two weeks ago, Microsoft announced that "Skype for Business" is emerged into Microsoft Teams. Great!

2. Documents should not be allowed to be copied from SharePoint Sites to "Teams Files".

It's much better to just create a file link in Microsoft Teams.

3. Outlook Group should be renamed as "Shared Inbox".

The details are described in this post

4. Yammer should be part of SharePoint site, instead of a separate product.

5. All documents should be forced to store in SharePoint Document Library.

In other tools (apps), the documents should be attached at a "file link".

[update, 20170722]

6. Unified API

For example, developers should be able to connect to different APPS by one API command.

[update, 20170726]

7. Add "Fast List" to SharePoint Online

"Fast List" needs to be as fast as SQL table, so all Office 365 items, including conversations, calendar events, etc. can all be stored in SharePoint Online.

[update, 20170731]

8. SPFX solution need "site collection" level deployment scope

"For SharePoint Framework solutions, there is only one deployment scope: tenant wide. Once added, and enabled, in the App Catalog, the SharePoint Framework solution will be available to all Site Collections."

https://github.com/SharePoint/sp-dev-docs/blob/master/docs/spfx/enterprise-guidance.md#sharepoint-framework-deployment-scopes

When should we use "Office 365 Groups"?

[updated regarding "Group Identity", 2017-07-04]

There are quite a lot of posts (such as here, here, and here) trying to explain what "Office 365 Groups" is. But, after reading them, I am still confused.

"Office 365 Groups" covers many areas: Azure AD, permission management, document depository (SharePoint sites), email (Exchange Online), group chat (Microsoft Teams), Yammer, etc. But,

• When should Group be used?
• Should we convert existing Email Distribution List into Group automatically, during the migration to Office 365?
• Should we allow users to create new Group when they believe it is necessary?
• Should we use Group Site to replace normal "Team Site"?
• Should we create a Group for a new project?
• Can one user belong to more than one Group?

After months of investigation, finally, I got my own conclusion. However, it is so faraway from the mainstream opinion, it even shocked myself!

There is only one principle: Office 365 Group should be based on basic "Group Identity Job Role".

Why? Because Group is designed to conquer the challenge of communication around group. Let me explain it through an use two cases here.

1. Communication between a person and a team

A user, let's say, Tom, needs help from DBA team to fix a database issue.

Obviously Tom doesn't care which member of the DBA team can help, and he just want the problem get resolved. The procedure may take months, existing DBA member may takes annual leave or even resign, new DBA may join the team at anytime. The communication between Tom and DBA team should not be affected by the those events, and it happens in many apps, such as SharePoint, Yammer, Outlook, Microsoft Teams, etc.

In other words, Tom wants to talk to DBA team, instead of any specific DBA, without the obstacles of permission management, information sharing, action history tracking.

That's why we need Group. Group should only be created for the bottom level, most basic organisation unit, just above individual user.

We should create a Group for DBA team (if there is more than one DBA in the team, and they all look after all databases), but not for IT department (because there is no such job role called "IT staff").

2. Communication in a team which needs to be shared across the whole team

For small projects, if it needs a lot of communication and those communication need to be shared across the whole team, then, it's better to create a group for it.

So, group members can use different tools to talk to each other, and don't need to worry about permission management or missing relevant project information.

=========

Now, it's easy to answer the previous questions.

• When should it be used?

For each job role, if there are more than one person share the same responsibility, we should create a Group for them.

Normally it's just a few users, but, in some special case, for a role like "help desk", there could be more than 30 people.

• Should we convert existing Email Distribution List into Group automatically, during the migration to Office 365?

No.

Unless the DL is created exactly for a job role.

• Should we allow users to create new Group when they believe it is necessary?

No.

Users should contact Office 365 administrators to create it.

• Should we use Group Site to replace normal "Team Site" during migration (from On-Premise to Office 365)?

No.

Unless the existing team site is created exactly for a job role.

• Should we create a Group for a new project?

It depends.

Normally it's needed for small projects.

• Can one user belong to more than one Group?

Normally, no.

Unless he/she happens to take two roles in two teams.

I know many people have different thoughts about "Office 365 Groups". Any comments are welcome!

PS 1: Microsoft Teams are perfect Application for Office 365 Group. We can create a new team/channel for each topic/task.

PS 2: Microsoft Teams really should be part of "Skype for Business".

PS 3: Documents should not be copied from SharePoint Sites to "Teams Files". It's much better to just create a file link in Microsoft Teams.

SharePoint needs lightning fast list and library

After the performance test last time , I realized that SharePoint was still so slow comparing to database system (such as SQL Server). I understand that SharePoint is designed for "people access", not a data repository for other computer system, from the very beginning.

But things are changed.

For current enterprises, SharePoint and commercial database system are the major places to host data. Database is fast, but it's really designed for developers. Normal business users cannot easily create tables, add columns, enter data, and manage the whole database. So, they don't have choice. If there are some data they want to share with other people, they have to put it into SharePoint. What if they want to share 50,000 records? They have to copy them to a SharePoint list. It's painfully slow.

We know why SharePoint is so slow. It provides item-level permission control, versioning, auditing......What if users don't need those features, and just want to share a lot of data with other people or another computer system?

That's what is needed: fast list and library. Users still can create list, add/remove columns, create list view......but no other extra features. It's like a database table in SharePoint, but we still can use CAML query to retrieve data, we still create create list views.

If the list/library is created for people access, it should be based on traditional list templates. If we just need something similar to database table, then we can use "fast list".

"Fast list" is even critical for Office 365: if Microsoft wants to use SharePoint as the major place to host data, performance is extremely important.

By the way, do we still need MS Access then?   :-)

Office 365 portal is awkward, confusing and daunting

It's really designed by and for developers. :-)

How many users are there happy to spend time to get familiar with these 18 icons, to figure out which one they should click, and then start to work there?

What users want to do here?

1. Create / modify a document (OneDrive, SharePoint, Video, Word, Excel, PowerPoint, OneNote, Sway)
2. Talk / contact some one. (Mail, People, Groups. Where's Lync?)
3. Figure out what need to do. (Mail, Calendar, Planner, Tasks, Delve)
4. Web surfing. (Yammer, Newsfeed, Delve)

If users could only see 4 entry icons here, I believe that they would feel much more comfortable.

But, it's still a bit messy.

SharePoint is the place to store information. Are emails information? How about People contact details? Calendar events? Tasks? Why so much information is stored in other separate places?

If we could store all information in SharePoint, then many of those services could be moved into SharePoint User Profile module, such as Mail, People, Groups, Calendar, Planner, Tasks, Yammer, Newsfeed. (OneDrive and Delve are already there)

We even don't need Microsoft Graph anymore! That's a big relief to developers, as they only need to learn how to access SharePoint data.

Do you like this idea?  Any comments are welcome!

[update, 2016-09-29]

If a document needs to be shared in SPO, Yammer, Planner and Groups, does that mean that the same document has 4 separate copies?

To manage the versions and permissions of this document must be hard.  :-)