Lookup columns include workflow status columns, traditional lookup columns to other lists, and person/group columns. This includes the two default people fields “Created by” and “Modified by”. If your list has more than 12 of these, you may receive the following error:
“This view cannot be displayed because the number of lookup and workflow status columns it contains exceeds the threshold (12) enforced by the administrator.”
In SharePoint Online, you’re not able to increase the lookup column limit. Lists created prior to the June 2013 CU update are capped at 8 lookup columns, while those afterward are allowed 12.
However, on-premise SharePoint (server) allows you to change this limit to your heart’s content.
You might run into this issue when running task processes in SharePoint Designer.
“Reason: The user who attempted to complete the task is not the user to whom the task is assigned.”
Assuming the person should actually be able to complete the task, check the following:
Make sure the user who was assigned the task does not have multiple accounts. If they do, the task could have been assigned to the account that the person isn’t currently signed in as when attempting to complete the task.
If it’s someone completing the task on behalf of another, make sure that individual is either:
A Site Owner (site settings, site permissions, people and groups, site owners) or
Task process owner (in SPD 2010 workflows, go to the properties for the task step and set task process owner. Click OK and republish workflow.):
SharePoint lists have a default limit of 5,000 items per view. But lists can contain 30 million items (just not all available in one view). Since you’re reading this, perhaps you’ve already learned this from an error message such as:
The view cannot be displayed because it exceeds the list view threshold (5000 items) enforced by the administrator.
To view items, try selecting another view or creating a new view. If you do not have sufficient permissions to create views for this list, ask your administrator to modify the view so that it conforms to the list view threshold.
First of all, when in doubt, refer to the documentation provided by Microsoft. Read it carefully to understand limitations in your specific environment, explanations of various actions and rules and the permissions required to correct the issue.
If you’ve seen a similar notification, I empathize with your pain. I don’t know that there is one solution to this problem, either, so I’m going to share a number of them we’ve used and hope that one (or all) of them will help you.
Basically a file is added through file explorer (a cloud library in OneDrive or SharePoint being synced locally to your computer) but then after a moment a notification appears which says “You now have two copies of a file; we couldn’t merge the changes in [filename]” and then the filename is appended with your computer name again and again until eventually the filename is too long and is harder to delete. Let’s not get to that point.
SharePoint Designer 2013 workflows verify email recipients as valid SharePoint users. If they’re not on your site they likely won’t be able to receive an email from a 2013 workflow depending on your setup. Even though the workflow publishes, the recipient could be removed before the message is sent. You may also get this error message when creating the workflow:
“The selected user(s) may not be valid on the site this workflow is published on. If a recipient is not a valid SharePoint user, he or she will not receive workflow emails.”
More often than not, this will be triggered by any yahoo, gmail, hotmail, etc. address but can also sometimes occur with addresses within your organization if they’re not in your AD and properly part of your site. I recommend copying yourself in testing to be sure the message is sent to external users if you think you’ve successfully made external addresses valid SharePoint users.
But to be certain you get around this 2013 obstacle, simply use a 2010 workflow. SharePoint Designer workflows built on the 2010 platform do not verify addresses. And if you’ve already built a complicated masterpiece in 2013, no need to fret. You can always create a 2010 workflow just for the email and start it within your 2013 workflow.
Update 9/1/17: If that still doesn’t work…
Most likely your recipients, then, aren’t being looked up in an item field (perhaps the same address will be used for all workflow instances). In your workflow before the email step, “Create a workflow variable” and set it to the person(s’) email address(es). If multiple, type as semi-colon delimited. Set the variable type to string. Then for the To: line in the email, use a workflow lookup to that new variable.
If you’ve found this post by search, you’ve likely already gone into the workflow settings for a particular list or document library item and have clicked the info icon () next to “Internal status” and found that your workflow is “in progress”, but has an error: “Access Denied. You do not have permission to perform this action or access this resource.” Peering into the bulk of the message, you see a helpful tidbit that includes sp.utilities.utility.SendEmail. This could be from a number of causes, but here are the summaries of three possible solutions. Note that the first solution is still required even if you try B or C below. I’ve only included the second and third solutions as additional possibilities if the first doesn’t solve your problem.
A common question, before we begin, is what level of permissions any individual needs to be able to send an email or start a workflow generally. It doesn’t matter so much if you’re using Impersonation or App Steps, but the quick answer is a minimum of Contribute level permissions is good.
Lookup columns aren’t friendly to a lot of things. Power BI reports, calculated columns, creating new items via workflow when both lists have lookup columns, if/then statements, etc. Especially when your lookup column is looking up to a list from another site, not the same subsite in which you’re working.
A previous scenario required that I create a new item in a different site’s list when conditions were met in the origin site’s list item. Both lists used the same lookup column, and I received the “lookup is in another web” error when trying to do a direct copy via workflow, from lookup column to lookup column. The solution ended up being creating a new item in a temporary, lookup-free list that received the lookup values just as text. Then SharePoint Designer copied those over to the final list, which received the text and happily converted it back to the appropriate lookup values. See the full solution here.
This post will focus on the same error message, but this time is triggered by a SharePoint Designer workflow in a different scenario where we just want to convert our lookup values to text so we can use them for various purposes.
To save you time, I also tried (and failed) at these potential solutions before finding success:
Setting workflow variables to the lookup values and trying to set the variables to text values, or use the variables in my if/then statements to create new text values (this defeats the purpose of using lookup columns, of course)
Using a number of combinations of Microsoft Flow and SharePoint Designer to get the data from the lookup column extracted then “pasted” back in as text
So let’s get to the solution. Feel free to comment with your scenario specifics – I’ve had a lot of experience with this error, and would be happy to help.
The people column’s settings are multiple selection, people AND groups as can be seen here. This is absolutely fine (multiple selection, mixing of permission groups with individuals). You may just note the warning in red in the screenshot below:
“Earlier versions of client programs might not support a Person or Group field that allows multiple selections. Adding this field might block those programs from saving documents to this library.”
In your workflow, just make sure you’re returning your people column “As String” and not any of the semi-colon delimited options. That’s all there is to it. Publish the revision and run the workflow again (and you may need/wish to go in and end any workflows that errored out but are still “running”). Best of luck!
Perhaps you, like me, built an exciting Microsoft Flow workflow and let it go into the wild without much additional thought. But at some point, you drop a lookup column into the mix and your Flow stops working. It tells you the field is not supported in query, even if that specific field isn’t being utilized in the Flow. I believe this has something to do with REST, but we won’t dwell on the cause – let’s get to the workaround.
The scenario I’ll be using is my cross-site publishing alternative using Microsoft Flow where I’m basically copying data from list items in one site collection to create new list items in a different site collection. This is helpful when someone does some sort of data entry once, and other people are then entering much of the exact same data. This copies all of the overlapping data to a new list item for the second site collection to reduce duplication of work.
It sounds simple but with a lookup column in the destination list we get the error. For this I’ll be using SharePoint Designer and Microsoft Flow (of course) in combination, though you could certainly try it all in Microsoft Flow. I just find parts of the process simpler in SPD. And while your origin data may be different (MailChimp, Twitter, etc.), and your exact scenario may differ, this workaround should still have value in concept.