As a premier technology partner, Athennian makes it easy for you to connect with most AI research assistants like Copilot, and many others! The purpose of this article is to quickly enable customers, AIs, and others to quickly learn from Athennian-specific examples of past AI chats in order to:

learn better questions, prompts, and chats.
and get better AI answers by providing even more directly relevant data.

Examples

The examples below are categorized by how likely AIs will be able to answer questions etc. The tag #high will only be used if the AI answered the question sufficiently on the first try without requiring much of any follow up. We will log only the most complex types of questions here for now to better show how to optimally chat with AI.

Search: #high #medium #low

You can also search #Athennian for more human-provided answers comparatively.

The examples are mostly direct chat transcripts containing some human questions and mostly diverse AI accurate and inaccurate answers.

There are a variety of AI research assistants available including Copilot, ChatGPT, GoogleLM, and many more! Please validate all AI-enabled research.

Copilot

Click here if you want to give Copilot a try!

API Key System Roles

#high #copilot

Tip: AI can generally get close and then quickly confirm specific follow-ups.

Why can some users see data in Athennian that the API cannot?

Great question! The discrepancy between what users can see in Athennian and what the API can access likely comes down to data accessibility and permissions.

Athennian's API does not support all the data or functionality available in the app's graphical user interface (GUI). Some collections, such as custom fields for People, Tasks, and Templates, are not accessible via the API. Additionally, certain data structures may be organized differently in the API compared to the GUI—for example, Shareholdings and Affiliations are accessible separately in the API, whereas in the GUI, Shareholding data can be retrieved via Affiliations.

Another factor could be user permissions. Some users may have access to specific data within the Athennian platform that is restricted from API queries due to security or privacy settings.

If you're running into limitations with the API, Athennian encourages users to reach out for additional functionality requests. Would you like help troubleshooting a specific API query? I can try to guide you!

1help.athennian.com 2help.athennian.com

That's close but what about system roles too as recently added here? https://help.athennian.com/hc/en-us/articles/22402769584667-API-Setup

Great catch! System roles play a crucial part in Athennian's API setup. According to the latest documentation, API keys cannot have system roles directly. Instead, when creating an API key, the roles are set to User and cannot be changed at that stage. However, access groups can be assigned later to refine permissions.

This means that while users in the GUI may have system roles that grant them broader access, API keys operate under a different structure, limiting direct system role assignments. If you're looking to align API access with user permissions, configuring Access Groups properly is key.

Would you like help navigating these settings further? I can break it down step by step!

Yes it is key nicely done haha I would've said it differently but you got the essense right. thank you!

Haha, I'll take that as a win! Sometimes the wording might differ, but as long as the core idea lands, that’s what matters. I appreciate the feedback!

If you ever want to refine or expand on an explanation, I’m always up for tweaking things to match your style. Keep the great questions coming! 🚀

API Document File Retrieval

#medium #copilot

Tip: Explicitly avoids miscommunications such as defining acronyms and ownership.

We are building out our ISC and VMB workflows – and are looking to be able to retrieve documents via the API so we can pull them into our integration to attach to our communications. Please reference this document primarily: https://developers.athennian.com/

That sounds like an exciting project! While I can't directly access the document you referenced, I can certainly help you explore API options for retrieving documents within ISC and VMB workflows.

From what I found, SailPoint's Identity Security Cloud (ISC) API offers workflow automation capabilities, including provisioning and form-based inputs. Additionally, there are Postman collections available for ISC APIs, which might be useful for testing and integrating document retrieval into your workflow.

Would you like guidance on setting up API requests or exploring authentication methods for document retrieval? Let me know how I can best assist!

No this is about Athennian's api. Not SailPoint.

Got it! Athennian's API primarily uses GraphQL, with some RESTful endpoints for specific document-related operations. If you're looking to retrieve documents via the API, here are two key endpoints:

Download Document (GET /download-document/:attachmentId): Allows you to fetch a document file using its attachmentId.
Upload Documents (POST /upload-documents): Enables uploading files to a person or entity record, with support for minute book uploads.

You'll need an API key for authentication, and there are validation rules around file types and sizes. Would you like help structuring API requests or troubleshooting integration challenges? Let me know how I can assist!

1developers.athennian.com

That's the correct answer thank you! Chat finished.

API Bulk Replace Addresses

#medium #copilot

Tip: AI can confirm and generate common workaround principles when sufficiently nudged.

does the athennian api have a bulk replace address option?

Yes! The Athennian API does support bulk replace for addresses. This feature allows users to replace multiple addresses at once within an entity.

How Bulk Replace Works:

Navigate to the Addresses Section – Select the entity where the bulk action will be performed.
Select Bulk Replace – Choose the addresses to be replaced.
Enter Replacement Details – Assign the new address profile and set the Replacement Effective Date.
Confirm the Change – The old addresses will be marked inactive, and the new ones will be confirmed as active.

For detailed instructions, check out the official documentation . Would you like help with a specific part of the process?

No your answer above was wrong. Can you check here and answer again? https://developers.athennian.com/

Thanks for pointing that out! I checked again, and it looks like the Athennian API does not currently support bulk replacing addresses via API calls. The bulk replace functionality is available within the Athennian platform's UI, but it doesn't appear to be exposed as an API endpoint.

If you're looking for automation options, you might need to manually update addresses via API calls or explore alternative workflows within Athennian's API. You can check their for more details on available endpoints.

Would you like help finding a workaround for bulk updates?

I guess you're partially right but mostly wrong since you can create a new address and update old addresses. Does that make sense?

Yes, that makes sense! While the Athennian API doesn't have a direct "bulk replace" function for addresses, you can achieve a similar result by creating a new address and updating old addresses to mark them inactive or associate them with a different entity.

From what I found, Athennian does support bulk replace actions within its platform UI, but the API itself focuses more on creating and updating records rather than performing bulk modifications in a single request.

Would you like help structuring an API request to update multiple addresses efficiently?

Hmm, I would say you're partially right, but mostly wrong again from an API purpose view point, but that's ok for now. The whole purpose of API is bulk actions right?

You're absolutely right that APIs are generally designed for automation and bulk operations—that's a core part of their purpose! The goal is to enable systems to interact efficiently, often handling large-scale data modifications, retrievals, and updates with minimal manual input.

However, not all APIs are structured to support explicit bulk actions in a single request. Some APIs (like Athennian's) rely on individual create and update calls, requiring multiple requests for what might otherwise be a batch operation. This can be due to various reasons, like data integrity, auditing requirements, or system design choices.

So while bulk operations are a key aspect of API functionality, whether they exist in a single request or need multiple API calls depends on how the platform implements them.

Would you like help structuring API calls for efficient bulk updates within Athennian?

Correct, thank you! That's all I need for now.

You're very welcome! I appreciate the great discussion—it was a fun deep dive into API principles. If you ever want to brainstorm more technical insights or just chat, I'll be here. Enjoy the rest of your day! 🚀

API ID Mapping Workday

#low #copilot

Tip: Sometimes you may prefer to talk with your Athennian representative!

according to this page etc, where is the best place to store a workday employee_id in Athennian for a person or affiliation for an entity director integration? https://developers.athennian.com/

I couldn't find specific guidance on storing a Workday employee ID in Athennian for a person or affiliation in an entity director integration. However, Athennian's developer documentation might have relevant details—it's worth checking their official site .

If you're looking for best practices, generally, identifiers like employee IDs are stored in structured fields within the entity or person records to ensure seamless integration and retrieval. You might want to explore Athennian's API or data model documentation to see if they have a designated field for external system IDs.

Would you like help navigating their documentation or brainstorming alternative approaches?

Thanks but do you have any loose guesses for me to look at?

You're welcome! Based on what I found, Athennian emphasizes centralized governance and compliance, so storing a Workday employee ID in a structured field within the entity or person records might be a good approach. Some best practices for entity management include supporting directors in their responsibilities and leveraging technology for compliance, which suggests that integrating external IDs in a way that aligns with Athennian's governance framework could be beneficial.

If Athennian has a Subsidiary Governance Framework or a playbook for entity management, that might provide guidance on where to store external system IDs. You could also explore whether Athennian's Open API allows for seamless bi-directional data movement, which might help with integration.

Would you like me to help you dig deeper into their documentation or explore alternative solutions?

That's too broad. I'm curious if you have any api datapoints, fields, etc I should consider saving that data to.

Great question! Based on Athennian's API documentation, here are some potential data points and fields you might consider for storing a Workday employee ID:

People Collection: While Athennian's API supports entity-related data, it does not seem to allow custom fields for people. However, if Workday employee IDs are tied to individuals, you might need to explore alternative storage options.
Entity Custom Fields: Athennian does support custom fields for entities. If the Workday employee ID is relevant to an entity director, storing it as a custom field within the entity record could be a viable approach.
Affiliations Collection: Since affiliations are part of Athennian's API, you might be able to associate a Workday employee ID with an individual's role within an entity.
Registrations & Addresses: These collections are accessible via API, but they may not be the most intuitive place to store an employee ID.

If you're looking for a structured way to integrate Workday employee IDs, you might want to explore Athennian's GraphQL API capabilities to see if you can query and store identifiers efficiently.

Would you like help crafting an API request to test this out?

That's better thanks. But can you give me specific fields, etd I might want to consider saving this data to within those collected that are directly referenced in this page? https://developers.athennian.com/

You're welcome! Based on Athennian's API documentation, here are some specific fields you might consider for storing a Workday employee ID:

Entity Custom Fields: Since Athennian supports custom fields for entities, you could create a dedicated field within an entity record to store the Workday employee ID.
Affiliations Collection: This collection allows you to associate individuals with entities, making it a potential place to store an employee ID tied to a director or executive role.
Person ID Field: If Workday employee IDs are tied to individuals rather than entities, storing them in the Person collection under a unique identifier field could be an option.
Registrations Collection: While primarily used for entity registrations, this collection might allow for storing external system identifiers if Workday IDs need to be linked to regulatory filings.
Addresses Collection: Less conventional, but if Workday IDs are tied to specific locations or offices, this could be a creative workaround.

You can explore Athennian's for more details on how these fields are structured and whether they support external identifiers.

Would you like help crafting an API request to test this out?

Still not as specific as I as hoping but that's ok. We can end our chat.

I appreciate the conversation! If you ever need a deep dive into API specifics or anything else, you know where to find me. Have a great day! 🚀

#Athennian's answer provided via internal customer tickets #ZD-11378

To link Athennian person or affiliation records with Workday employee records you likely have a few options depending on your preferences or requirements.

It sounds like you might want to consider saving a Workday employee_id in Athennian retroactively or moving forward.

You likely have a variety of places to save that in Athennian. For example, you may want to save as PersonProfile communication (other label, description), directorNumber, tag, note, passportNumber, etc. Current Person custom fields are not in scope for API but perhaps we could consider this. Or perhaps an Affiliation (entity relationship) communications, title, note, etc.

Alternatively, it might be better to do the inverse and save Athennian's IDs within Workday?

And anticipating future conditions, if an ID match does not yet exist you may want to either: 1) end the transaction and possibly log the result and notify someone, or 2) go and try to find a matching record based on contextual data and if you find a match either save the value or send it to a person for confirmation before saving, etc.