Cómo recopilar requisitos de seguridad en Salesforce

Recopilar requisitos de seguridad puede parecer un reto incómodo. Como administrador/consultor, no es realista asumir que los usuarios finales comprenden los diversos matices de seguridad de Salesforce, como funciones, perfiles, conjuntos de permisos, grupos de conjuntos de permisos, silenciamiento, conjuntos de uso compartido, uso compartido implícito y la distinción entre uso compartido manual y programático;

Por lo tanto, surge la siguiente pregunta: ¿cómo puede recopilar requisitos de forma eficaz y articularlos de forma directa y permitir a los usuarios comunicar quién ve qué en Salesforce de forma precisa? En este artículo, exploro varios escenarios destinados a incorporar estratégicamente medidas de seguridad en su sistema. El objetivo es garantizar la formulación óptima de requisitos para el desarrollo de un modelo de seguridad robusto.

Reunir requisitos de seguridad con los usuarios de negocio

Cuando participe en el proceso de recopilación de requisitos de seguridad con usuarios empresariales, independientemente de su función como administrador, analista empresarial o consultor, es esencial abordar la interacción asumiendo que los usuarios empresariales pueden no estar familiarizados con las distinciones entre funciones y perfiles/conjuntos de permisos en Salesforce. 

Para facilitar una sesión de recopilación de requisitos más eficaz, es aconsejable venir preparado con un conjunto de preguntas específicas que garanticen un diálogo más fluido y productivo. En el escenario en el que está discutiendo el objeto Cuenta, haga las siguientes preguntas a su usuario de negocio:

Pregunta al usuario de negocio: ¿Qué personas deberían poder ver Cuentas?;

Respuesta del usuario de negocio: Como mínimo, todo el mundo debería poder ver todas las Cuentas.

Qué significa esto para usted: Genial – ahora sabes lo que significa en términos de valores predeterminados en toda la organización (OWD). Significa Sólo Lectura Pública en Cuentas. Todas las personas deben tener un objeto mínimo de Lectura en Cuenta. Como consultor, debes saber que sólo hacer el OWD Público de Sólo Lectura no otorga a los usuarios Lectura en Cuenta si no tienen el permiso, ya sea a través de su perfil o conjuntos de permisos (ahora deberías estar usando más los conjuntos de permisos debido a la eventual jubilación de los perfiles), para Leer Cuentas;

Pregunta de seguimiento para el usuario empresarial: Ahora que ha dicho que todos los usuarios deberían poder ver las Cuentas, ¿qué usuarios específicos deberían poder editar y eliminar las Cuentas de su propiedad? Explique el concepto de propiedad de registros. La propiedad de los registros se puede hacer mediante la creación del registro o la transferencia debido a un proceso de negocio como alguien que deja la organización o conceptos más avanzados como Enterprise Territory Management;

Respuesta del usuario empresarial: Queremos que nuestros representantes de ventas puedan editar sus propias cuentas. Normalmente, son ellos los que deben ser propietarios de la Cuenta. Tenemos excepciones a la regla de que sólo los representantes de ventas deben editar sus cuentas, ya que queremos que nuestros equipos de finanzas editen todas las Cuentas independientemente de la propiedad;

Después de todo, van a entrar en el límite de crédito y si debemos mantener en hacer más negocios con la cuenta si están atrasados en sus pagos. También queremos que los gerentes de ventas, a quienes los representantes de ventas reportan, editen sus propias cuentas de representantes;

Lo que esto significa para usted: A partir del conjunto anterior de requisitos, usted entiende que:

1. Los representantes de ventas deben poder leer y editar sus Cuentas. 
2. Los gestores de ventas deben estar por encima de los representantes de ventas en la jerarquía de roles.
3. Los representantes de ventas y los gestores de ventas pueden compartir el mismo conjunto de permisos a nivel de objeto (perfiles o conjuntos de permisos), pero los gestores de ventas deben estar por encima en la jerarquía de roles para poder editar las Cuentas de los representantes de ventas. Puede que sea demasiado pronto para determinar si los representantes de ventas y los gestores de ventas pueden compartir los mismos permisos (perfiles o conjuntos de permisos), pero si determina mediante una ronda de preguntas que los representantes de ventas y los gestores de ventas tienen todos los mismos permisos a nivel de objeto, entonces la jerarquía de funciones es la clave. Reconozca los patrones y las capacidades de los personajes para diseñar su modelo de seguridad.
5. Diseñe su propio modelo de seguridad

Pregunta de seguimiento al usuario empresarial: Respecto a las excepciones para los usuarios de finanzas, el usuario de negocio sugirió que los equipos de finanzas deben poder editar todas las Cuentas. Sin embargo, aludió a atributos específicos como el límite de crédito y la cuenta retenida. Por lo tanto, su pregunta de seguimiento debería ser: ¿deberían poder editar otros atributos de la cuenta, como la dirección de facturación, la dirección de envío y otros atributos?

Respuesta del usuario comercial: Los usuarios de finanzas deberían poder editar el límite de crédito, la retención de la Cuenta, la dirección de facturación y los campos de contacto de facturación en todas las Cuentas. Pero no deberían editar nada más;

Qué significa esto para usted: Del conjunto de requisitos anteriores, se deduce que:

1. Los usuarios de Finanzas deben tener acceso a todas las Cuentas. Puede resolver esto colocándolos en la parte superior de la jerarquía de roles o creando una regla de uso compartido.
   1. Los usuarios de Finanzas deben tener acceso a todas las Cuentas
   2. Los usuarios de Finanzas deben tener permisos de lectura y edición a nivel de objeto aprovisionados ya sea con perfiles o conjuntos de permisos. 
   3. No todos los atributos deben ser editables por los usuarios de finanzas. Esto le indica que se trata de detalles de seguridad a nivel de campo. Recuerde detallar esto en su historia de usuario para que la seguridad a nivel de campo se describa correctamente. 

   Pregunta al usuario de negocio: Conociendo su negocio, quiere averiguar si hay algún matiz en el acceso a los registros entre los gestores de ventas de Estados Unidos y Canadá. Quiere saber si estos gestores deben poder editar las Cuentas de los demás. Si son propietarios de alguna Cuenta, ¿deberían poder editar las Cuentas de sus representantes de ventas?

   Respuesta del usuario comercial: Sólo los gerentes de Estados Unidos pueden editar sus propias cuentas y las cuentas de los representantes de ventas a su cargo. También deben poder editar las cuentas que pertenezcan al director de ventas canadiense y a los representantes de ventas que dependan del director de ventas canadiense. Sin embargo, el gerente canadiense sólo debe ser capaz de ver todas las cuentas y ser capaz de editar sólo las cuentas de su propiedad y de su equipo;

   Lo que esto significa para usted:

   1. Tiene que haber una jerarquía de roles separada para EE.UU. y Canadá.
   2. Los usuarios de EE
   3. Tiene que haber una regla de uso compartido para que el gestor de EE.UU. pueda editar Cuentas propiedad del gestor de ventas de Canadá y sus subordinados.

   Pregunta al usuario empresarial: ¿Existe alguna excepción o algún proceso empresarial oculto o no mencionado que deba conocer? 

   Respuesta del usuario de negocio: Cuando una Cuenta está en espera debido a pagos vencidos, entonces un gestor de disputas debe ser capaz de editar ciertos atributos en la Cuenta en caso de resolución o añadir notas adicionales sobre cobros. ;

   Qué significa esto para usted: 

   1. El rol de esta persona puede ser una rama por sí sola hasta que se determine a través de una ronda de preguntas. Esta persona sólo necesita editar Cuentas cuando una Cuenta está en espera. Esto significa que debe haber una regla de compartición basada en criterios basada en el atributo Cuenta retenida.
   2. Esta persona sólo necesita editar Cuentas cuando una Cuenta está retenida
   3. De nuevo, esta persona debe tener lectura y edición en Cuenta también, ya que esto define el permiso de nivel base. La regla de uso compartido solo permite editar las cuentas que no son de su propiedad

   Al no ser técnicos con el usuario empresarial, pudimos solicitar requisitos que abarcaban muchos conceptos de seguridad en Salesforce, como perfiles y conjuntos de permisos, funciones y jerarquía, reglas de uso compartido basadas en funciones, reglas de uso compartido basadas en criterios y seguridad a nivel de campo. Con esto se pretende iniciar la conversación sobre cómo separar los términos técnicos al conversar con sus usuarios empresariales;

   Cómo-los-escenarios-anteriores-se-traducen-a-historias-de-usuario

   1. Como usuario del sistema, me gustaría tener la capacidad de acceder y ver fácilmente todas las cuentas. Esto me permitirá mantenerme informado sobre nuestros clientes actuales, clientes potenciales, clientes pasados, competidores y proveedores, fomentando una comprensión más fluida de nuestras relaciones comerciales.
   2. Como representante de ventas, me gustaría tener la posibilidad de acceder y ver fácilmente todas las cuentas
   3. Como representante de ventas, necesito la capacidad de ver todas las cuentas y editar las cuentas que poseo para poder mantener mis cuentas actualizadas.
   5. Como director de ventas que gestiona cuentas con sede en EE.UU., necesito poder ver todas las cuentas y editar las cuentas que son propiedad de los directores de ventas canadienses y las cuentas de su equipo para poder realizar cualquier actualización necesaria en nuestro negocio canadiense.
   7. Como usuario de finanzas, necesito la capacidad de leer y modificar todas las cuentas, independientemente de la propiedad, mientras que sólo selectivamente editar atributos específicos en la cuenta. Esto significa que puedo actualizar y gestionar eficientemente la información financiera esencial asociada a cada cuenta. 
   9. Como gestor de disputas, necesito la capacidad de ver y editar todas las cuentas, independientemente de quién sea su propietario. También editaré de forma selectiva atributos específicos de la cuenta, solo cuando una cuenta esté en espera por problemas relacionados con el pago.

   Pensamientos finales

   No espere que los usuarios de su empresa le digan exactamente cómo debe diseñarse la seguridad en Salesforce. Al mismo tiempo, no espere que consiga el modelo correcto en su primer intento. Unas cuantas veces se dará cuenta de que está creando exactamente la misma persona (perfil/grupo de conjuntos de permisos) dos veces con la única diferencia de que una persona necesita editar registros que no posee. Esto significa que esta persona es un papel que se sienta encima de la otra persona en la forma de la jerarquía de roles.

   No espere que sus usuarios de negocio entiendan todos los conceptos como roles, perfiles, conjuntos de permisos, etc. Estos son sus conceptos y debe desglosarlos en un lenguaje sencillo para que los usuarios empresariales no se sientan abrumados al intentar comprender la terminología de Salesforce;

   Debe conocer a fondo sus fundamentos para poder mantener una buena conversación y captar requisitos importantes. Sí, las cosas cambian con cada versión de Salesforce, pero los fundamentos de seguridad no han cambiado tan drásticamente. Los conjuntos de permisos están sustituyendo poco a poco a los perfiles, pero se trata más de un cambio lateral que de un cambio drástico. Ahora existen reglas de restricción que hacen que el modelo de uso compartido sea más interesante y complejo a pesar de que los fundamentos sean los mismos. Cuanto más profundices en los fundamentos, más cómodo te sentirás discutiendo estos conceptos en términos no técnicos.