There are certain cases where you can do everything you’d think is required to setup an editable Entity Form, yet for some reason it keeps appearing as read-only. In this post, I’ll explain why. Spoiler alert: I don’t have a great workaround for this problem, but to save some other people the headache of trying to figure out what’s going on, I thought I’d put together a quick post.

The Problem

The issue was first brought to my attention by this thread in the community forums. The original poster was asking for help getting an entity form to be editable – despite having successfully setup editable entity forms before, they couldn’t figure out how to make one configured for Service Appointment editable.

If you’re looking to make an Entity Form editable, there are a couple things to check:

• Make sure that the Entity Form is set to Edit (not Insert or Read-only).
• Ensure that the portal user has Write Entity Permissions on the record in question. This includes ensuring that Entity Permissions exists for that record type, that the portal user is linked to the Entity Permission via a Web Role, and that the Entity Permission would apply to the specific record that is trying to be edited.

In this particular case, the original poster had done this correctly. So why was their Entity Form still showing up as read-only?

The Reason

It turns out, it’s because of the type of entity they were trying to edit: Service Appointment, as well as what I’d consider to be a bug in the Portal code.

Service Appointment is one of those entities with more than just the standard statecode values. Most entities have Active [0] and Inactive [1]. However, according to this documentation, Service Appointment has Open [0], Closed [1], Cancelled [2], and Scheduled [3]. Depending on how you create the Service Appointment, it will often start with an initial value of Scheduled [3].

Since we’ve got access to the source code of Portals (or at least an old version of the source code), I was able to determine that in addition to checking Entity Permissions, the code also checks the statecode of record being edited – if the statecode isn’t 0, it will display a read-only version of the form (see line 585 in the code linked above).

This was done to prohibit editing of deactivated records. However, as we can see in this case, just because a record’s statecode isn’t 0, that doesn’t mean it isn’t active. For Service Appointment, Scheduled is an active state. For this reason, I consider this to be a bug.

At this point I don’t have a great workaround. One option would be to ensure that your Service Appointments are set to Open instead of Scheduled. Or perhaps you could create another entity that acts as a front to the Service Appointment (although that sounds like a LOT of work). I have reported the bug to Microsoft, but I expect this might be low on their priority list. But at least now, if you run into an Entity Form that seems to be read-only no matter what you do, this might give you a clue as to what’s going on.