The Current Process — and the Opportunity to Automate
Where the ATL ORAT team spends manual effort today, and why it is a strong candidate for automation.
What Citiri is
Citiri (CitiriOS) is an owner scope management platform built on Salesforce, the world’s most widely trusted enterprise cloud. Because Citiri lives on Salesforce, it inherits enterprise-grade security, identity, and audit controls, and it can connect to the other systems an airport already runs. This is the only place in this document where we refer to “Salesforce” by name — everywhere after this, we simply call the platform and its features Citiri.
How ATL ORAT handles asset files today
When a new System or piece of Equipment is documented, the ATL ORAT team receives the files through one of two channels — a physical thumb drive or a SharePoint location — and then performs several manual steps to make those files usable for stakeholders.
Why this is worth automating
- It is slow and repetitive. Every file is handled by a person multiple times — received, uploaded, linked, and re-keyed — which does not scale as the volume of Systems & Equipment grows.
- It is error-prone. Manually copying links and pasting them onto the correct asset record invites mismatches, broken links, and files that land in the wrong place.
- Public links are a security concern. Manually created public links can be forwarded, are hard to revoke, and do not respect who should be allowed to see a given document.
- There is no reliable audit trail. When linking is manual, it is difficult to prove which stakeholder received which document, and when.
- It ties up skilled ORAT staff in clerical work instead of readiness and activation.
The opportunity
Every step above is a rules-based, repeatable action — exactly the kind of work software does well. By connecting the systems that already hold this information, the Citiri team can remove the manual upload, linking, and data-entry steps entirely, so that dropping a file onto a system automatically publishes it to the right stakeholders and updates the matching asset record. The remainder of this document lays out two building blocks: an optional SharePoint intake integration, and the core CITIWorks ↔ Citiri integration.
Optional: A SharePoint Intake Integration Optional
Automatically pulling incoming asset files from SharePoint into Citiri — if ATL chooses to enable it.
One of the two ways ATL ORAT receives files today is SharePoint. If ATL would like to remove the “download from SharePoint, then re-upload into Citiri” step, we can build a connection that lets Citiri reach into a designated SharePoint location and bring new files in on its own. We present this as optional because it depends on how ATL’s SharePoint is set up.
Important reality check from IT
ATL’s IT group has previously advised us that SharePoint at ATL is generally used as a personal / individual repository rather than an organization-level (tenant-governed) repository. An automated integration needs a stable, organization-owned SharePoint site or library — not a personal folder that belongs to one employee’s account and can disappear when roles change. Confirming (or creating) an org-level location is the first prerequisite before this option is viable.
How the connection would work (in plain terms)
Microsoft exposes SharePoint content through a secure REST API called Microsoft Graph — think of it as an official, guarded “service door” that approved applications can use to request files. Citiri would knock on that door using a modern, token-based sign-in standard (OAuth 2.0): rather than storing anyone’s password, Microsoft issues Citiri a time-limited, revocable access token that grants only the specific, pre-approved permissions. Citiri then checks the designated location for new files and pulls them in automatically.
What must be set up
- An organization-level SharePoint site/library designated as the official intake location.
- An app registration in Microsoft Entra ID (formerly Azure AD) that represents Citiri to Microsoft.
- Graph API permissions scoped to only what is needed (for example, read access to the specific site’s files — Sites.Read / Files.Read), following least-privilege.
- Admin consent granted to those permissions inside ATL’s Microsoft 365 tenant.
- A secured credential (an external / named credential) stored on the Citiri side so the token is managed safely.
Security & permissions
- Least privilege: the connection is limited to a single intake location and read-only access — nothing more.
- Named service identity vs. per-user: ATL decides whether files are pulled by one governed service identity or in the context of each user’s own SharePoint permissions.
- Revocable & auditable: access is a token that can be revoked at any time, and every retrieval is logged.
- No stored passwords: authentication is delegated to Microsoft’s identity platform.
A SharePoint / Microsoft 365 administrator must be involved
The app registration, the permission scoping, and especially the admin consent step can only be performed by someone with administrative rights in ATL’s Microsoft 365 tenant (typically a SharePoint or Global administrator). We (the Citiri team) will define exactly what is needed, provide the values to enter, and do the Citiri-side configuration — but ATL must designate an authorized SharePoint admin to establish the org-level location and approve the connection. Without that person, this optional integration cannot proceed.
Note: native connectivity is primarily designed to read/reference SharePoint content. If ATL later wants two-way movement, that is achievable through the same Graph API but would be scoped as additional work.
The Core Solution: A CITIWorks ↔ Citiri Integration
Two connected pieces of work that together remove the manual upload, linking, and data-entry steps.
Part A — Auto-connect systems to their file libraries Work we can do independently
The first piece links each system record in Citiri (Citiri__System__c) to the correct
Citiri Files library / folder, and wires that folder into the right project so it appears
automatically in the Stakeholder Portal, shared with the appropriate audience.
Because this work lives entirely inside Citiri, our team can build and test it independently — it does not require ATL to stand up anything new. The outcome for ORAT:
This replaces “manually upload, then manually create a public link” with governed, permission-aware sharing — no loose public URLs.
Part B — Auto-populate the CITIWorks asset URL fields
The second piece closes the loop with CITIWorks. Once a file is published to the correct system library in Citiri, the integration automatically writes the link back into the URL field of the matching CITIWorks asset record — the exact step the ORAT team performs by hand today.
What our research shows about CITIWorks
CITIWorks is a GIS-centric enterprise asset management system built on Esri’s ArcGIS. Importantly for this project, it provides a RESTful API (its web-services layer) for reading and updating records such as Equipment and asset entities, and it supports event triggers (its “Action Manager” / webhooks) that can notify other systems when something changes. In practical terms, that means Citiri and CITIWorks can exchange information programmatically rather than through copy-and-paste.
How the two systems will talk (in plain terms)
Think of it as two clerks passing notes through a locked mail slot. When a file is published in Citiri, Citiri sends a secure message through CITIWorks’ API that says, in effect, “for asset X, set the document URL to this link.” CITIWorks verifies the request is authorized, updates the asset record, and confirms back. No person re-types anything, and the two records stay in sync.
What we (the Citiri team) will build
- The connection and secure sign-in between Citiri and CITIWorks.
- The field mapping — which system/asset in one platform equals which record in the other, and which URL field to populate.
- The automation logic, error handling, and retry behavior.
- Testing against sample records before anything touches production data.
Security items ATL will need to provide
- The CITIWorks Web Services / API license add-on enabled (API access is a licensed capability).
- A dedicated API service account / token scoped with least privilege (only the assets and fields in play).
- Network access to the CITIWorks API endpoint (any required IP allow-listing / firewall rules).
- Confirmation of the asset fields and identifiers to map, from a CITIWorks administrator.
Who does what
Responsibility is shared, but the build is ours. ATL’s role is primarily to grant access and confirm mappings.
| Task | Owner | Notes |
|---|---|---|
| Design & build both integrations | Citiri team (we) | Connection, mappings, automation, testing. |
| Part A: system-to-library automation inside Citiri | Citiri team (we) | Can proceed independently — no ATL dependency. |
| Enable CITIWorks API/Web Services license | ATL | Licensed capability; must be turned on. |
| Provide CITIWorks API service account & access | ATL | Least-privilege credential + network access. |
| Confirm asset field mappings & identifiers | Joint | CITIWorks admin + our team. |
| (Optional) Org-level SharePoint + admin consent | ATL | SharePoint / M365 admin required (Section 2). |
How we will roll it out — in careful batches
To protect ATL’s live data, we will not build directly against production. We will move through four controlled stages, proving the integration on test data before it ever touches real records.
Sandbox CITIWorks (test records) ↔ Sandbox Citiri
Build and validate the full flow end-to-end using disposable test records only. Zero risk to production; this is where we confirm mappings, permissions, and behavior.
Promote the Citiri side to Production
Once proven, we deploy the Citiri-side work (including Part A) into production Citiri, still pointed at safe test targets on the CITIWorks side.
Connect Production CITIWorks
Finally, we point the live integration at production CITIWorks and validate on a small, controlled set of real assets before full cut-over.
The sequence is deliberate: prove in sandbox → production Citiri → production CITIWorks. Each stage gates the next.
Risk: delayed responses cost time
This is a coordinated effort. At several points we will be blocked waiting on ATL — enabling the CITIWorks API license, issuing the API service account, granting network access, confirming field mappings, and (if pursued) SharePoint admin consent. Each of these hand-offs sits on the critical path. If responses or approvals are delayed, the timeline slips directly by that amount, and momentum built in the sandbox can be lost. Prompt turnaround on access and approvals is the single biggest factor in delivering this quickly. We ask ATL to name responsible points of contact for CITIWorks, IT/network, and (optionally) SharePoint up front so we can keep the batches moving.
Summary: Section 1 shows that today’s receive → upload → link → populate routine is manual and ripe for automation. Section 2 offers an optional SharePoint intake connection (dependent on an org-level location and a SharePoint admin). Section 3 is the core: the Citiri team builds a CITIWorks ↔ Citiri integration — auto-filing files into system libraries (our independent work) and auto-populating CITIWorks asset URL fields — rolled out in safe batches, with prompt ATL responses being key to speed.