Now, when testing this in a different environment, tasks are being created and I guess immediately deleted?

For the sake of testing, I went to a different environment, made a new SharePoint group with a few test accounts and myself. I have a WF that assigns a task to that SharePoint group. I create an item on the list, all the notifications get fired off. Every one of the test users have a task that is deleted? I have a web part on a page on the same site that shows all the tasks assigned to current user. Immediately after making a new item on the list, each test user gets an item listed on that web part that says

"

What kind of permissions have they on the site/lists?

I've verified that the same group has contribute to the site and the list. Then I added them directly when that didn't work.

trying to go to the task gives an "unexpected error". I checked the log file. All I get is the below:

Actually, I found another part that says the item does not exist.

11/13/2017 13:19:13.20 w3wp.exe (0x0C7C) 0x15EC SharePoint Foundation Runtime tkau Unexpected System.ArgumentException: Item does not exist. It may have been deleted by another user.
at Microsoft.SharePoint.SPList.GetItemById(String strId, Int32 id, String strRootFolder, Boolean cacheRowsetAndId, String strViewFields, Boolean bDatesInUtc, Boolean bExpandQuery)
at Nintex.Workflow.NWListWorkflowContext.get_WorkflowInstance() f18f2c9e-9980-c090-ac19-21621f0d3662

What about the task permissions?

You could create a new Nintex Task List and assign it on your workflow design.

It's inheriting the permissions from the site it's on. I checked and they have Contribute permissions there as well. 

This is definitely a permissions issue. When I get the SharePoint group Full Control they can access the tasks. Why would contribute permissions not be enough though?

can you check the permissions on your tasks or main list that you haven't changed the

list settings > advanced settings > item-level permissions section...?

Yea, I realized Nintex had an issue with Flexi tasks when item-level permissions were set late yesterday. That's a fun little thing to work around.

So did you find a solution?

Found out what doesn't work. Didn't find out why. Marked an answer anyhow. Just something to work around.

NJ, I had this same issue some time ago. You must parse the names in the group. I have attached a snippet from the workflow I used.

I was in the same boat with this issue. Not sure if this will work for everyone but I created a flexi task to send to an associates email and then auto forward it to the group mailbox, using a Outlook rule, based off of subject line. This person was then able to go to the group mailbox and go to the email body and respond to the task with no problem. Everything ran perfectly.

 Note: I enabled the option to delegate but it didn't appear to have needed it in this case.