Estamos habilitando esto para todos los clientes de Workday Push mediante un lanzamiento gradual. Nos pondremos en contacto con usted para organizar los cambios de permisos necesarios. Si tiene alguna pregunta o consulta, póngase en contacto con su gerente de éxito del cliente.

Descripción general

Beamery ha realizado una actualización integral de sus canalizaciones de Workday Push Integrations a la versión v44.1 de la API SOAP de Workday. Esta actualización mejora el rendimiento, la estabilidad y la integridad de los datos de la plataforma, y presenta varias mejoras clave que no estaban disponibles con la versión anterior de la API (v31.2).

Actualizaciones clave

• Rendimiento y estabilidad: La canalización anterior enviaba todos los campos de los candidatos y todas las candidaturas asociadas en una única solicitud Put_Candidate de gran tamaño, lo que provocaba tiempos de espera agotados y una degradación del rendimiento. La actualización desacopla las canalizaciones y optimiza las cargas de datos.
• Integridad de los datos: La actualización garantiza una mejor integridad de los datos y resuelve las limitaciones de la API anterior. Por ejemplo, la API v31.2 no podía enviar los segundos nombres de los candidatos de EE. UU.; la v44.1 resuelve este problema.

Qué cambia

1. Actualización de la API de Workday Candidate Push
   La canalización de Workday Candidates Push ahora utiliza la versión v44.1 de la API de Workday Put_Candidate (también utiliza Get_Candidates y Get_References).
    

   Campo/Área	Antes	Después
   Actualizaciones de campos del candidato (nombre, ubicación, teléfono)	Todos los campos se enviaban independientemente de si se habían modificado.	Solo se envían los campos modificados (nombre, ubicación, teléfono), lo que evita sobrescrituras innecesarias.
   Candidatos combinados	Se enviaban actualizaciones, pero la API devolvía falsos positivos sin realizar ninguna actualización.	Ya no se envían actualizaciones para los candidatos combinados en Workday pero no en Beamery. Ahora se gestionan como rechazos.
   Tipo de dispositivo telefónico	No era obligatorio; se utilizaba "Mobile" de forma predeterminada.	Es obligatorio en v44.1. La asignación comprueba primero la configuración y, después, coincide con el tipo disponible más cercano, utilizando "Mobile" como último recurso.
   URL de Twitter/X	Se enviaba tanto en el campo Website data como en el campo Social Network Username.	Se envía únicamente como Website data. Social Network Username ya no funciona como se esperaba en la API actual.
   Segundo nombre	No se enviaba para candidatos de EE. UU. (limitación de v31.2) ni para países no compatibles.	Ahora se envía para candidatos de EE. UU. Sigue sin enviarse para países no compatibles (Canadá, Reino Unido, India, etc.).
   Empleado existente (Worker_Reference)	Podía sobrescribir campos restringidos del candidato, lo que provocaba errores no notificados.	La v44.1 aplica las restricciones. El nombre, la ubicación, el correo electrónico, el teléfono, el sitio web y las redes sociales NO se envían para los registros que tienen un Worker_Reference. Las etiquetas y los datos del currículum del prospecto SÍ se siguen enviando.
   Datos del prospecto (resumen, habilidades, experiencia)	Se enviaban a todas las candidaturas nuevas y existentes.	Se envían únicamente a las candidaturas nuevas y al perfil del prospecto (no a las candidaturas preexistentes). Si no existe un perfil de prospecto, se activará uno.

2. Workday Application Push — Canalización desacoplada
   Se ha implementado una canalización independiente para Workday Application Push, que también utiliza v44.1 Put_Candidate.
   Cambio clave: los datos del currículum de la candidatura (resumen, habilidades, experiencia) ahora se envían únicamente para las candidaturas nuevas. Las candidaturas existentes ya no reciben datos actualizados del currículum mediante este proceso.
3. Workday Attachment Push — Canalización desacoplada
   Workday Attachment Push ahora es una canalización desacoplada que utiliza v44.1 Put_Candidate_Attachment. No hay ningún cambio en la funcionalidad ni en el comportamiento; esto se ajusta a la implementación anterior, en la que los archivos adjuntos utilizaban una solicitud de API independiente.

Cambio de permisos

• La actualización de la API SOAP v31.2 a la v44.1 requiere un cambio de permisos para el contenido Resume_Data.
• Campos afectados: 
  • Prospect_Data.Prospect
  • Resume_Data.Summary
  • Resume_Data.Skill_Data
  • Resume_Data.Experience_Data
• Permiso necesario:
  • "PUT Candidate Data: Attachments"

Sin este permiso, el sistema devuelve: "You don’t have security access to add or make changes to a prospect’s attachments."

Si ya tiene habilitado el envío de archivos adjuntos, este permiso ya está configurado y no es necesario realizar ninguna acción.

--

Cómo añadir o validar nuevos permisos para la cuenta ISU

Para añadir o validar permisos para una cuenta ISU, consulte la sección "Assign Domain Security Policies" del artículo sobre la creación de cuentas ISU de Workday y siga los pasos que se indican a continuación:

Comprobar los permisos actuales:
Como se describe en el paso 4 del artículo, puede revisar los permisos existentes accediendo a la página View Integration System Security Group.

• Localice el Integration System Security Group asociado al Integration System User de Beamery.
• En la tabla Domain Security Policy Permissions, busque el permiso: "Candidate Data: Attachments" con la operación PUT .
• Verifique si este permiso ya se ha concedido.

• Siga el paso 5 y vaya a la página Maintain Domain Permissions for Security Group.
• En la sección Integration Permissions, dentro del cuadro de selección Domain Security Policies permitting Put access, añada el permiso necesario: "Candidate Data: Attachments"

• Complete la tarea del paso 6: Activate your security policy changes .

• Este paso es necesario para garantizar que las actualizaciones se apliquen y que el cambio de permisos se implemente por completo.

   

Notas importantes

• Si su tenant de Workday requiere "Source" como campo obligatorio cuando se activan los perfiles de prospectos, deberá crear una nueva fuente "Beamery" mediante la tarea Maintain Recruiting Sources en Workday.
• Las URL de LinkedIn y Facebook se siguen transmitiendo en el campo Social Network URLs.

• Workday ya no admite operaciones Get ni Put para candidatos combinados en las versiones recientes de la API.

   

Preguntas frecuentes

• ¿Por qué han desacoplado Candidates y Applications en el envío?
  • La combinación del envío de ambos en una única solicitud de API provocaba tiempos de procesamiento más largos y frecuentes tiempos de espera agotados de las solicitudes. Separarlos reduce el riesgo de tiempos de procesamiento prolongados y errores de envío.
• ¿Qué implica este desacoplamiento para el envío independiente de candidaturas?
  • Ahora las candidaturas son una entidad propia dentro del modelo de datos de Beamery, en consonancia con el modelo de datos de Workday. Anteriormente, las actualizaciones de habilidades, experiencia y resumen se enviaban tanto a las candidaturas nuevas como a las antiguas. Ahora se envían únicamente a las candidaturas nuevas.
• ¿Qué ocurre cuando no hay un perfil de prospecto en Workday?
  • Las habilidades, la experiencia y el resumen se envían al perfil del prospecto mediante Candidate Push. Si no existe un perfil de prospecto, se activará y completará uno. Las nuevas candidaturas creadas a partir del perfil del prospecto heredarán las actualizaciones más recientes.
• ¿Por qué se requiere el permiso PUT Candidate Data: Attachments incluso sin archivos adjuntos?
  • Workday hizo que los permisos fueran más granulares a partir de v43.1 (versión 2024R2). Las habilidades, la experiencia y el resumen forman parte de "Resume Data" en el modelo de datos de Workday, y este permiso es necesario para actualizar esos datos. Incluso sin habilitar el envío de archivos adjuntos, el permiso sigue siendo necesario. Esto se verificó en colaboración con Workday.