PBX Feature Requests

Custom fields for extensions

• Open
• Subscribe

---

David S

It would be nice to have the ability to create one or more custom fields for users, at least boolean checkboxes but also text and/or other field types, that could be created in Manager Portal Pro on a global for reseller or per-customer basis (at least visibiliy-wise), ideally with the ability to control the permissions on visibilty and updates per role (for example, visible to Office Managers or Basic Users but not editable, or just editable by Office Managers but not visible at all to Basic Users). Resellers would always be able to see/edit them.

These custom fields should be visible as optional columns in the Users display, and be updatable in bulk with the bulk update methods. They should also be a part of the user's individual profile.

The custom fields and their values would definitely also need to be available via API query, and ideally, to avoid the need for polling frequently, changing a custom field value should also send a webhook call to a URL defined by the reseller with the custom field and contain enough information to identify the record being edited by the API along with the updated valuie of the custom field with its name (contained in JSON post).

The custom field integration should either provide or allow for the creation of a secret key sent to the webhook for authentication as a bearer token.

This would allow for extensive custom integrations such as enabling or disabling third party VoIP applications, or allow for custom adjustments to other third party systems through the control panel at the request of resellers or end users (whether admin/office manager or not), depending on need and billable questions as determined by the reseller in custom field configuration.

With a robust enough system, custom integrations would be possible by resellers without additional development from OIT required in many cases, although custom OIT-developed integrations would still be ideal where possible due to server infrastructure and coding requirements that would still be required with custom fields.

(A well-done, but perhaps overengineered for purpose, custom field example is the custom fields for NinjaOne/NinjaRMM, especially the permissions, types, and tiering of multi-level fields, many of which are nice to have but not all are requirements to be useful here.)