Mixing
SharePoint Data Strategy
Our organisation is looking to make the move to the cloud using SharePoint Online as the basis for a full-fledged document management system. We are however struggling to map our organisational structure to SharePoint and wonder whether we are going to bump into SharePoint's limitations.
In essence we have a board of directors which uses a central "case" list to organise and manage its work. There are several thousand cases in the list (going back a couple of decades) and around 10 new cases are added each week. Then there are several departments each of which are responsible for creating, analysing, and managing some of the cases, but with strictly defined permissions such that groups of staff in each department can only view and work with cases related to them. As such we could probably define up-to 10 distinct security groups to which individuals could be added. Also new board members would have limited access to some historical cases earlier than their time of election.
All of this seems to make for a complex scenario requiring heavy use of item-level permissions in the "case" list which apparently has an upper limit of 5,000 in SharePoint online.
We would very much appreciate any advice regarding our thinking process and the suitability of SharePoint for the scenario we have at hand.
Many thanks.
sharepoint sharepoint-online
asked Jan 1 at 4:52
KiaKia
155
add a comment |
Our organisation is looking to make the move to the cloud using SharePoint Online as the basis for a full-fledged document management system. We are however struggling to map our organisational structure to SharePoint and wonder whether we are going to bump into SharePoint's limitations.
In essence we have a board of directors which uses a central "case" list to organise and manage its work. There are several thousand cases in the list (going back a couple of decades) and around 10 new cases are added each week. Then there are several departments each of which are responsible for creating, analysing, and managing some of the cases, but with strictly defined permissions such that groups of staff in each department can only view and work with cases related to them. As such we could probably define up-to 10 distinct security groups to which individuals could be added. Also new board members would have limited access to some historical cases earlier than their time of election.
All of this seems to make for a complex scenario requiring heavy use of item-level permissions in the "case" list which apparently has an upper limit of 5,000 in SharePoint online.
We would very much appreciate any advice regarding our thinking process and the suitability of SharePoint for the scenario we have at hand.
Many thanks.
sharepoint sharepoint-online
asked Jan 1 at 4:52
KiaKia
155
add a comment |
Our organisation is looking to make the move to the cloud using SharePoint Online as the basis for a full-fledged document management system. We are however struggling to map our organisational structure to SharePoint and wonder whether we are going to bump into SharePoint's limitations.
In essence we have a board of directors which uses a central "case" list to organise and manage its work. There are several thousand cases in the list (going back a couple of decades) and around 10 new cases are added each week. Then there are several departments each of which are responsible for creating, analysing, and managing some of the cases, but with strictly defined permissions such that groups of staff in each department can only view and work with cases related to them. As such we could probably define up-to 10 distinct security groups to which individuals could be added. Also new board members would have limited access to some historical cases earlier than their time of election.
All of this seems to make for a complex scenario requiring heavy use of item-level permissions in the "case" list which apparently has an upper limit of 5,000 in SharePoint online.
We would very much appreciate any advice regarding our thinking process and the suitability of SharePoint for the scenario we have at hand.
Many thanks.
sharepoint sharepoint-online
asked Jan 1 at 4:52
KiaKia
155
Our organisation is looking to make the move to the cloud using SharePoint Online as the basis for a full-fledged document management system. We are however struggling to map our organisational structure to SharePoint and wonder whether we are going to bump into SharePoint's limitations.
In essence we have a board of directors which uses a central "case" list to organise and manage its work. There are several thousand cases in the list (going back a couple of decades) and around 10 new cases are added each week. Then there are several departments each of which are responsible for creating, analysing, and managing some of the cases, but with strictly defined permissions such that groups of staff in each department can only view and work with cases related to them. As such we could probably define up-to 10 distinct security groups to which individuals could be added. Also new board members would have limited access to some historical cases earlier than their time of election.
All of this seems to make for a complex scenario requiring heavy use of item-level permissions in the "case" list which apparently has an upper limit of 5,000 in SharePoint online.
We would very much appreciate any advice regarding our thinking process and the suitability of SharePoint for the scenario we have at hand.
Many thanks.
sharepoint sharepoint-online
sharepoint sharepoint-online
asked Jan 1 at 4:52
KiaKia
155
asked Jan 1 at 4:52
KiaKia
155
edited Jan 2 at 0:38
Kia
asked Jan 1 at 4:52
KiaKia
155
asked Jan 1 at 4:52
KiaKia
155
asked Jan 1 at 4:52
KiaKia
155
155
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Hello Kia and thanks for sharing your challenge,
a simple calculation leads me to believe that when talking about a couple of decades worth of cases AND assuming the constant rate of 10 new cases per week, we may be talking about ca. 10 000 cases at present with about 500 being added every year. I am also assuming that when you are mentioning the case list you also mean this as a literal SharePoint list. What you did not mention is the number of people that would go into each security group - of the 10 you have posited. SharePoint also has a 2000 member "limit" on each security scope - so even if you have individual permissions for each item, you still have to have all the users somewhere with at least Limited Access permissions.
So my recommendations would be:
If there are more than 2000 people in total who need access (keep in mind that older employees are usually not manually deleted from the permissions list) or if you believe that the 5000 individual ACLs will be reached and even surpassed - consider splitting the list in two (or more) Webs or in two Site Collections -> I will call them Current and Archive, but you could have an archive per Year or 5-year etc. as required. Consider doing this automatically using a PowerShell script/Event handler/Workflow etc. This way you will limit the number of security principals (i.e. users or groups) automatically. DO NOT be afraid of multiple Webs or even Site Collections, instead use Site Collections as much as possible. Make sure you split this in such a way that when a specific limit is reached the older entries are automatically moved. Examples: User limit, or individual ACL entries - you can determine this using a custom Timer Job / Webhook or Script or what have you at regular interval.
After implementing the above - I feel your pain, you are probably using custom code/workflows to create the cases and you are thinking "OMG, just changing all the instances to adapt to the new architecture is going to take a long time!" - but this depends of course on how well that part of the system was implemented. Now that you have multiple Webs or Site Collections you still need a sort of Dashboard where you can see and find all cases. I strongly recommend a search-based solution because the Search Service is very powerful and can even (see Hybrid Search) span Online and On-Premises Farms. This should be relatively easy to implement as you probably already have custom content types defined for your cases - so just create a custom search scope over all your archives and current case locations and use that to do the "Daily Work". The Search service is ACL-aware and does not have the limitations that List Views have.
So in short: Use Webs or Site Collections that are automatically created (Segmentation) when reaching certain thresholds - think of this as your storage backend. Then use a custom Search scope + Site/Search Center to expose your case items (frontend).
Let me know if I can offer further tips or assistance.
I also recommend this great example from Microsoft to get a new perspective on your permission architecture: MS Docs - Troubleshoot common fine grained permissions issues - you will need 1-2 cups of coffee but it is worth it.
answered Jan 2 at 19:45
RazvanRazvan
1427
Thank you very much Razvan. I found your comments and insights very helpful and still working through them and slowly digesting them. Thank you also for your kind offer of further assistance which I might take up at a later point. With regards to the size of our security groups, each one could have between 2 to 20 individuals assigned to it (around 100 staff in the whole organisation) so we seem to be well clear of that particular limitation.
– Kia
Jan 4 at 15:59
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53993080%2fsharepoint-data-strategy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Hello Kia and thanks for sharing your challenge,
a simple calculation leads me to believe that when talking about a couple of decades worth of cases AND assuming the constant rate of 10 new cases per week, we may be talking about ca. 10 000 cases at present with about 500 being added every year. I am also assuming that when you are mentioning the case list you also mean this as a literal SharePoint list. What you did not mention is the number of people that would go into each security group - of the 10 you have posited. SharePoint also has a 2000 member "limit" on each security scope - so even if you have individual permissions for each item, you still have to have all the users somewhere with at least Limited Access permissions.
So my recommendations would be:
If there are more than 2000 people in total who need access (keep in mind that older employees are usually not manually deleted from the permissions list) or if you believe that the 5000 individual ACLs will be reached and even surpassed - consider splitting the list in two (or more) Webs or in two Site Collections -> I will call them Current and Archive, but you could have an archive per Year or 5-year etc. as required. Consider doing this automatically using a PowerShell script/Event handler/Workflow etc. This way you will limit the number of security principals (i.e. users or groups) automatically. DO NOT be afraid of multiple Webs or even Site Collections, instead use Site Collections as much as possible. Make sure you split this in such a way that when a specific limit is reached the older entries are automatically moved. Examples: User limit, or individual ACL entries - you can determine this using a custom Timer Job / Webhook or Script or what have you at regular interval.
After implementing the above - I feel your pain, you are probably using custom code/workflows to create the cases and you are thinking "OMG, just changing all the instances to adapt to the new architecture is going to take a long time!" - but this depends of course on how well that part of the system was implemented. Now that you have multiple Webs or Site Collections you still need a sort of Dashboard where you can see and find all cases. I strongly recommend a search-based solution because the Search Service is very powerful and can even (see Hybrid Search) span Online and On-Premises Farms. This should be relatively easy to implement as you probably already have custom content types defined for your cases - so just create a custom search scope over all your archives and current case locations and use that to do the "Daily Work". The Search service is ACL-aware and does not have the limitations that List Views have.
So in short: Use Webs or Site Collections that are automatically created (Segmentation) when reaching certain thresholds - think of this as your storage backend. Then use a custom Search scope + Site/Search Center to expose your case items (frontend).
Let me know if I can offer further tips or assistance.
I also recommend this great example from Microsoft to get a new perspective on your permission architecture: MS Docs - Troubleshoot common fine grained permissions issues - you will need 1-2 cups of coffee but it is worth it.
answered Jan 2 at 19:45
RazvanRazvan
1427
Thank you very much Razvan. I found your comments and insights very helpful and still working through them and slowly digesting them. Thank you also for your kind offer of further assistance which I might take up at a later point. With regards to the size of our security groups, each one could have between 2 to 20 individuals assigned to it (around 100 staff in the whole organisation) so we seem to be well clear of that particular limitation.
– Kia
Jan 4 at 15:59
add a comment |
Hello Kia and thanks for sharing your challenge,
a simple calculation leads me to believe that when talking about a couple of decades worth of cases AND assuming the constant rate of 10 new cases per week, we may be talking about ca. 10 000 cases at present with about 500 being added every year. I am also assuming that when you are mentioning the case list you also mean this as a literal SharePoint list. What you did not mention is the number of people that would go into each security group - of the 10 you have posited. SharePoint also has a 2000 member "limit" on each security scope - so even if you have individual permissions for each item, you still have to have all the users somewhere with at least Limited Access permissions.
So my recommendations would be:
If there are more than 2000 people in total who need access (keep in mind that older employees are usually not manually deleted from the permissions list) or if you believe that the 5000 individual ACLs will be reached and even surpassed - consider splitting the list in two (or more) Webs or in two Site Collections -> I will call them Current and Archive, but you could have an archive per Year or 5-year etc. as required. Consider doing this automatically using a PowerShell script/Event handler/Workflow etc. This way you will limit the number of security principals (i.e. users or groups) automatically. DO NOT be afraid of multiple Webs or even Site Collections, instead use Site Collections as much as possible. Make sure you split this in such a way that when a specific limit is reached the older entries are automatically moved. Examples: User limit, or individual ACL entries - you can determine this using a custom Timer Job / Webhook or Script or what have you at regular interval.
After implementing the above - I feel your pain, you are probably using custom code/workflows to create the cases and you are thinking "OMG, just changing all the instances to adapt to the new architecture is going to take a long time!" - but this depends of course on how well that part of the system was implemented. Now that you have multiple Webs or Site Collections you still need a sort of Dashboard where you can see and find all cases. I strongly recommend a search-based solution because the Search Service is very powerful and can even (see Hybrid Search) span Online and On-Premises Farms. This should be relatively easy to implement as you probably already have custom content types defined for your cases - so just create a custom search scope over all your archives and current case locations and use that to do the "Daily Work". The Search service is ACL-aware and does not have the limitations that List Views have.
So in short: Use Webs or Site Collections that are automatically created (Segmentation) when reaching certain thresholds - think of this as your storage backend. Then use a custom Search scope + Site/Search Center to expose your case items (frontend).
Let me know if I can offer further tips or assistance.
I also recommend this great example from Microsoft to get a new perspective on your permission architecture: MS Docs - Troubleshoot common fine grained permissions issues - you will need 1-2 cups of coffee but it is worth it.
answered Jan 2 at 19:45
RazvanRazvan
1427
Thank you very much Razvan. I found your comments and insights very helpful and still working through them and slowly digesting them. Thank you also for your kind offer of further assistance which I might take up at a later point. With regards to the size of our security groups, each one could have between 2 to 20 individuals assigned to it (around 100 staff in the whole organisation) so we seem to be well clear of that particular limitation.
– Kia
Jan 4 at 15:59
add a comment |
Hello Kia and thanks for sharing your challenge,
a simple calculation leads me to believe that when talking about a couple of decades worth of cases AND assuming the constant rate of 10 new cases per week, we may be talking about ca. 10 000 cases at present with about 500 being added every year. I am also assuming that when you are mentioning the case list you also mean this as a literal SharePoint list. What you did not mention is the number of people that would go into each security group - of the 10 you have posited. SharePoint also has a 2000 member "limit" on each security scope - so even if you have individual permissions for each item, you still have to have all the users somewhere with at least Limited Access permissions.
So my recommendations would be:
If there are more than 2000 people in total who need access (keep in mind that older employees are usually not manually deleted from the permissions list) or if you believe that the 5000 individual ACLs will be reached and even surpassed - consider splitting the list in two (or more) Webs or in two Site Collections -> I will call them Current and Archive, but you could have an archive per Year or 5-year etc. as required. Consider doing this automatically using a PowerShell script/Event handler/Workflow etc. This way you will limit the number of security principals (i.e. users or groups) automatically. DO NOT be afraid of multiple Webs or even Site Collections, instead use Site Collections as much as possible. Make sure you split this in such a way that when a specific limit is reached the older entries are automatically moved. Examples: User limit, or individual ACL entries - you can determine this using a custom Timer Job / Webhook or Script or what have you at regular interval.
After implementing the above - I feel your pain, you are probably using custom code/workflows to create the cases and you are thinking "OMG, just changing all the instances to adapt to the new architecture is going to take a long time!" - but this depends of course on how well that part of the system was implemented. Now that you have multiple Webs or Site Collections you still need a sort of Dashboard where you can see and find all cases. I strongly recommend a search-based solution because the Search Service is very powerful and can even (see Hybrid Search) span Online and On-Premises Farms. This should be relatively easy to implement as you probably already have custom content types defined for your cases - so just create a custom search scope over all your archives and current case locations and use that to do the "Daily Work". The Search service is ACL-aware and does not have the limitations that List Views have.
So in short: Use Webs or Site Collections that are automatically created (Segmentation) when reaching certain thresholds - think of this as your storage backend. Then use a custom Search scope + Site/Search Center to expose your case items (frontend).
Let me know if I can offer further tips or assistance.
I also recommend this great example from Microsoft to get a new perspective on your permission architecture: MS Docs - Troubleshoot common fine grained permissions issues - you will need 1-2 cups of coffee but it is worth it.
answered Jan 2 at 19:45
RazvanRazvan
1427
Hello Kia and thanks for sharing your challenge,
a simple calculation leads me to believe that when talking about a couple of decades worth of cases AND assuming the constant rate of 10 new cases per week, we may be talking about ca. 10 000 cases at present with about 500 being added every year. I am also assuming that when you are mentioning the case list you also mean this as a literal SharePoint list. What you did not mention is the number of people that would go into each security group - of the 10 you have posited. SharePoint also has a 2000 member "limit" on each security scope - so even if you have individual permissions for each item, you still have to have all the users somewhere with at least Limited Access permissions.
So my recommendations would be:
If there are more than 2000 people in total who need access (keep in mind that older employees are usually not manually deleted from the permissions list) or if you believe that the 5000 individual ACLs will be reached and even surpassed - consider splitting the list in two (or more) Webs or in two Site Collections -> I will call them Current and Archive, but you could have an archive per Year or 5-year etc. as required. Consider doing this automatically using a PowerShell script/Event handler/Workflow etc. This way you will limit the number of security principals (i.e. users or groups) automatically. DO NOT be afraid of multiple Webs or even Site Collections, instead use Site Collections as much as possible. Make sure you split this in such a way that when a specific limit is reached the older entries are automatically moved. Examples: User limit, or individual ACL entries - you can determine this using a custom Timer Job / Webhook or Script or what have you at regular interval.
After implementing the above - I feel your pain, you are probably using custom code/workflows to create the cases and you are thinking "OMG, just changing all the instances to adapt to the new architecture is going to take a long time!" - but this depends of course on how well that part of the system was implemented. Now that you have multiple Webs or Site Collections you still need a sort of Dashboard where you can see and find all cases. I strongly recommend a search-based solution because the Search Service is very powerful and can even (see Hybrid Search) span Online and On-Premises Farms. This should be relatively easy to implement as you probably already have custom content types defined for your cases - so just create a custom search scope over all your archives and current case locations and use that to do the "Daily Work". The Search service is ACL-aware and does not have the limitations that List Views have.
So in short: Use Webs or Site Collections that are automatically created (Segmentation) when reaching certain thresholds - think of this as your storage backend. Then use a custom Search scope + Site/Search Center to expose your case items (frontend).
Let me know if I can offer further tips or assistance.
I also recommend this great example from Microsoft to get a new perspective on your permission architecture: MS Docs - Troubleshoot common fine grained permissions issues - you will need 1-2 cups of coffee but it is worth it.
answered Jan 2 at 19:45
RazvanRazvan
1427
answered Jan 2 at 19:45
RazvanRazvan
1427
answered Jan 2 at 19:45
RazvanRazvan
1427
answered Jan 2 at 19:45
RazvanRazvan
1427
1427
Thank you very much Razvan. I found your comments and insights very helpful and still working through them and slowly digesting them. Thank you also for your kind offer of further assistance which I might take up at a later point. With regards to the size of our security groups, each one could have between 2 to 20 individuals assigned to it (around 100 staff in the whole organisation) so we seem to be well clear of that particular limitation.
– Kia
Jan 4 at 15:59
add a comment |
Thank you very much Razvan. I found your comments and insights very helpful and still working through them and slowly digesting them. Thank you also for your kind offer of further assistance which I might take up at a later point. With regards to the size of our security groups, each one could have between 2 to 20 individuals assigned to it (around 100 staff in the whole organisation) so we seem to be well clear of that particular limitation.
– Kia
Jan 4 at 15:59
Thank you very much Razvan. I found your comments and insights very helpful and still working through them and slowly digesting them. Thank you also for your kind offer of further assistance which I might take up at a later point. With regards to the size of our security groups, each one could have between 2 to 20 individuals assigned to it (around 100 staff in the whole organisation) so we seem to be well clear of that particular limitation.
– Kia
Jan 4 at 15:59
Thank you very much Razvan. I found your comments and insights very helpful and still working through them and slowly digesting them. Thank you also for your kind offer of further assistance which I might take up at a later point. With regards to the size of our security groups, each one could have between 2 to 20 individuals assigned to it (around 100 staff in the whole organisation) so we seem to be well clear of that particular limitation.
– Kia
Jan 4 at 15:59
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53993080%2fsharepoint-data-strategy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
