it's doable by both ways, either appearance settings or rules.

but I would say in your scenario it would be easier/better to manage it by permission on the list. so one group of users that need to create items will get edit right and the other group that should have just read only access will get just read rights.

would that be an option for you?

I want all team members to be able to submit forms and also be able to read other team members submissions(and not be able to edit others submissions). Is this possible through Site Permissions?

In addition to all team members having read access to other team members submissions and being able to submit a form, we want the administrator of the form to have access to modify any of the responses on the form.

I would suggest following

- create a group READERS and put all the team members in there

- create a group ADMINS and put needed members in there

- within workflow use set permission action and assign permissions as follows

• set inherit permissions from parent to NO
• set remove existing permissions to YES
• give read permissions to READERS group
• give read/write (or full control?) permissions to ADMIN group
• give read/write permissions to item creator

Good suggestion, but I did just realize that we need to keep the Submitter with Edit permissions since we already have a workflow running that changes the form status with that team members security. If we created the workflow you recommended, it would cause the current workflow to stop.

So basically now I am looking to disable fields based on member groups and form status by using Rules or with the Field Settings, or potentially JavaScript. Any ideas on how I could do this?

but I did just realize that we need to keep the Submitter with Edit permissions

my suggestion solve it (give read/write permissions to item creator), doesn't it?

we already have a workflow running that changes the form status with that team members security

I haven't said you need to create a new workflow. it's just single workflow action, so you can add it to existing workflow.

I am looking to disable fields based on member groups and form status

I'm affraid you will not be able to achieve that.

you have one team which's members act in different roles for different items. so you would need different group(s) (members) for different items.

if you still want to do it within forms, what you could do is that you compare current user (common reference) to 'created by' list field (item property). if they do not match (+ possible check on form status) then disable editing.

but based on complexity of your form you might end up with plenty of duplicated rules to ensure that, so it becomes hard to maintain.

reg. of check for group membership in rules - despite IsMemberOfGroup runtime function is not available in the builder, if you copy&paste it there it will work (how to implement pending outcome task )

this approach should work for admins (I presume group of admins is stable and do not change with every item).

I think I have found a solution for this problem and appears to be working for me. I created a Calculated Value using fn-IsMemberOfGroup("ADMINS") and called this field isAdmin. Next, I created a rule for every field I wanted to disable using the condition and(isAdmin=="false", not(equals(Item Property: Form Status, "Creation"))) and checked the Disable box on the rule. This will disable the field if the team member is not an Admin when it's not in Creation status. When it is in Creation status, the team member will be able to edit the fields.

yes, that's the direction you might move to.

and what about your former requirement

I did just realize that we need to keep the Submitter with Edit permissions

if submitter is not member of admin group your rule doesn't allow him to edit item with status different from 'Creation', aka. after submit.

or have you relaxed your original requirements?

Next, I created a rule for every field

that might be at first hard to maintain and at second to have some side effects with rendering and accessing controls from javascript (if you needed that)

I would suggest to place single controls into panel(s) and apply rule on panels. even if you end up with placing single control into a panel it's still better option.

The Submitter needs Edit permission to the form so the workflow can work, however, the Submitter does not need Edit permissions to the fields.

ok, it was not clear from your description resp. I didn't caught it that way.

note that rules restrict changes just in form. they do not restrict permission on the item(s) itself, so other team members still could edit item ways out of form (quick edit ...)