Ingested Files (New)

Resource Lifecycle

After connecting Moveworks to your content system (like ServiceNow, Confluence, Google Drive, etc) and setting up ingestion, raw records (files, knowledge articles) are pulled in. These records then undergo processing and validation before being indexed in Moveworks and made available for serving.

Purpose of New Ingested Files Screen

Ingested Files Screen serves following use-cases for admins:

• Connected systems health: Monitor health of connected systems by reviewing whether Moveworks is able to successfully crawl and ingest files from your connected systems
• UAT of newly configured system: Validate if content is getting successfully ingested and indexed into Moveworks. Additionally validate if the count of ingested and serving records from your newly configured system is as per your expectation or not
• Periodic checks on key metrics: Keep periodic checks on ingested records, serving records, and non-serving records. Act swiftly on any deviation on these metrics
• Troubleshooting: Identify and resolve issues such as unhealthy systems, failed ingestion runs, permission ingestion failures, lower than expected file counts, missing files, files not serving to users, and file-level issues

Comparison: New and Legacy Interfaces

The updated ingested file screen comes with new capabilities including:

• Visibility into content and permission ingestion status
• View of total files ingested, serving files, and not serving files
• Ingestion and indexed timestamps details
• Permission ingestion status for each file
• Filtering and enhanced search
• Redesigned UI/UX

These improvements give Moveworks admins a comprehensive view of content imported from external systems and make content troubleshooting easier and more effective.

New View

Legacy View

New Ingested Files Screen Components

Ingestion Health Widgets

• Content Ingestion: Monitor file ingestion systems' health, view ingestion runs with logs, schedules (full and incremental), and error summaries, and quickly access connector and ingestion configs
• Permission Ingestion: Monitor permission ingestion systems' health, view ingestion runs with logs, schedules (full and incremental), and error summaries, and quickly access connector and ingestion configs

Read more about Data Ingestion: Data Ingestion View

❗️

Important Note

Please note, data ingestion viewer metrics should not be compared with the ingested knowledge, files, users, or forms screens within Moveworks Setup because these screen fundamentally serve different purposes.

Data Ingestion Viewer is primarily to monitor if Moveworks is able to connect to your configured system and whether Moveworks is able to successfully fetch raw records from your systems.

Ingested Knowledge, Files, Forms, and Users screens on the other hand is primarily used to monitor records that are available in the index, after it goes through the processing & indexing steps.

Ingested Records Widgets

• Ingested Files: Count of unique files crawled and ingested
• Serving Files: Count of unique files successfully processed and ready to serve to users
• Not Serving Files: Count of unique files that failed to process and are not currently serving to users

Ingested Records Table

• Last Indexed At (Table Header): Timestamp when the index was last updated (based on latest fetched file)
• External Record ID: The unique ID of a file fetched from your external system
• Title: The title of a file fetched from your external system
• Content Status: Whether a file is currently serving or not serving
• Connector: Name of the connector from which a file is ingested
• Permission Ingested: Whether permissions are ingested for a file from the external system (true/false)
• Last Ingested At: Timestamp when the content was last ingested
• Last Indexed At (Table column): Timestamp when a file was last indexed

🚧

Important Note: Ingested and Indexed timestamps may differ

When ingestion happens, there might be no updates to existing content. If no changes are found, the index is not updated.

Filters

• External ID: Filter files by their unique ID from the external system to quickly locate specific files
• Content Status: Filter files by their current status (Serving or Not Serving) to identify files available to users or troubleshoot issues
• Connector: Filter files by the connector source to view files from specific connectors (e.g., Google Drive, Box, SharePoint)

📘

Important Tip

You can combine multiple filters to narrow down results and find exactly what you're looking for.

Permission Checker

What is Permission Checker?

The Permission Checker tool allows Moveworks admins to verify whether a specific user has access to specific files by providing or selecting a user’s email address.

When to use Permission Checker?

• A user complains that they cannot find information from specific files in their search results, even though they should have access
• Admins have changed permissions, group memberships, or ACL rules in source system and want to confirm they are reflected in Moveworks
• After updating permission rules in Moveworks, admins need to validate that content permissions are reflected correctly
• Need to verify that new employees/UAT users can access expected content records
• Admins want to audit that sensitive HR, legal, or financial documents are only accessible to authorized personnel and not exposed to unauthorized users

How to Access Permission Checker in Moveworks Setup?

To access Permission Checker in Moveworks Setup:

1. Navigate to Moveworks Setup

   

2. In Enterprise Search left nav section, expand Enterprise Search → Answers → Ingested Knowledge

   

3. Select Files screen

   

4. Click on any record in the table

   

5. View the Permission Checker tool

   

How to Use Permission Checker in MW Setup?

1. Review your current permission strategy

   • The permission details section displays the following details:

     • Permission Strategy: Shows the permission strategy configured for this connector in Core Platform > Resource Permissions > Permission Rules screen > Strategy Config
       • If ReBAC strategy is selected, it displays Native Permissions
       • If ABAC or Public to all members of the organization is selected, it displays Moveworks Enforced Permissions
     • Additional Restrictions: DSL rules that layer additional access filters on top of existing permissions mirrored from the source system, providing granular control over who can view specific content. Configured in Core Platform > Resource Permissions > Permission Rules > Additional Restrictions config.
     • Additional Access: DSL rules that let Moveworks admins define extra audiences who are allowed to see certain records on top of the existing mirrored permissions. This explicitly adds access rather than restricts it. Configured in Core Platform > Resource Permissions > Permission Rules > Additional Access config.

     🚧

     Important Note: ServiceNow-specific Callouts

     1. Additional Access configuration is only applicable and displayed for ServiceNow connectors.

     2. The Permission Crawled field for ServiceNow always shows 'Not Available' - this is a known limitation as ServiceNow ACL permissions are not displayed in Moveworks Setup. The 'Not Available' status does not reflect the actual ingestion state of ServiceNow permissions.

        

     Learn more about Resource Permissions here

2. Click 'View Permission For User' → Select or enter the user's email address → Click 'View Permission'
3. Review the results
   1. Has permission: True - User can access this content
   2. Has permission: False - User cannot access this content
   3. If there’s any issue in evaluating the permissions, you will see the following errors:

      1. User profile not found. Please verify whether the user exists in Moveworks.: This user doesn't exist in the Moveworks platform to evaluate permissions. Please check whether the user is ingested in User Identity > Imported Users > All Users.

         

      2. Unable to test user permissions - permission data could not be found. Please try again later.: Permission data from your source system is not ingested yet. Please verify in Permissions Crawling widget or Customer Data Crawling Viewer that permissions have been successfully ingested.

         

      3. Unable to test user permissions - permission rules not found. Please configure permission rules and try again: Permission strategy has not been defined for this connector. Please verify whether Permission Rules exist for the connector.

         

      4. Unable to test user permissions - internal system error occurred. Please try again later.: There's an internal error at Moveworks - this will be resolved by our team. Reach out to Support if this issue persists.

❗️

Important Note:

If permissions are not ingested, '0 Permission Ingested' error is displayed.

FAQs

1. What does content serving or not serving mean?

   • Serving: The content has been successfully processed and indexed, and is ready to be served to end users
   • Not serving: Moveworks couldn't process and index the content. This typically happens when content isn't in the proper format or when there's a large drop in files that prevents processing

2. What does the permission ingested column mean?

   • Permission ingested – true: Permissions have been successfully ingested for these records
   • Permission ingested – false: This can mean two things:
     • Missing permissions: Permissions exist but haven't been ingested for this record yet
     • Not applicable: Permissions don't apply to this type of record

3. What does '0/1 healthy' or '8/10 healthy' mean in the ingestion widgets?

   • This shows how many of your configured systems are currently healthy. For example, "1/10 healthy" means 1 out of your 10 configured systems is healthy

4. What is the difference between last ingested at and last indexed at?

   • Last ingested: The timestamp when we successfully pulled a record from the external system as part of our data ingestion processes
   • Last indexed: The timestamp when we updated our index after detecting changes to a content record

   👉

   Important Note

   Last ingested at may be recent but last indexed at may be older because we continuously ingest records but only update the index when changes are detected to the content records.

5. Does the ingested files count represent the sum of serving and not serving files?

   • Yes, the ingested files count represents the total of both serving and not serving files combined

6. Is SNOW ACL supported or not?

   • Currently, we do not support showing ServiceNow ACL permissions flow in our permissions view. This feature is on our future roadmap

7. Count of successfully ingested records in the view logs does not match with the ingested records in ingested Knowledge/Files/Users/Forms screen. Is this expected?

   • Yes, this is expected. Data ingestion viewer shows count of records ingested in each full or incremental runs. Post which the records go through a series of processing and validation steps, before reaching the index and to the serving state. Therefore we must not compare the view log metrics with the ingested resource screens

8. When content has both Native Permissions and Additional Restrictions or Additional Access (only for ServiceNow) configured, how is access determined?

   • Permission Checker applies Additional Restrictions or Additional Access on top of Native Permissions using AND logic - both the native source permissions AND the additional DSL rules must allow access for the result to show "True.”

9. I see "Native Permissions" as the permission strategy but ‘-’ in the Additional Restrictions - does this mean no restrictions are applied?

   • Correct, if Additional Rules shows "-" or is empty, only the source system's native permissions are being used without any additional Moveworks-defined restrictions.

10. Does Permission Checker work for ServiceNow content even though ACL permissions aren't displayed in the UI?

    • Yes, Permission Checker can evaluate ServiceNow content permissions, but we do not support showing ACL ingestion yet.

11. Why does ServiceNow content show "Permission Ingested: Not Available"?

    • Currently, this is a known limitation as ServiceNow Access Control List (ACL) permissions are not currently displayed within the Permission Crawling View. The "Not Available" status does not reflect the actual ingestion state of ServiceNow permissions.

12. After updating permissions in the external system, how long should I wait before testing with Permission Checker?

    • Wait for your next scheduled ingestion cycle to complete - Permission Checker reflects permissions as of the last successful ingestion, not real-time source system changes.

13. Can I use Permission Checker to bulk test multiple users against the same document?

    • No, Permission Checker supports individual user testing only.

14. Why is Additional Access visible sometimes and not other times?

    • Additional Access configuration is only available for ServiceNow connectors. It will not appear for other connector types.

15. I’m getting Unable to test user permissions - internal system error occurred. error, what should I do?

    • This indicates an internal system error. Please try again in a few minutes. If the error persists, reach out to support for assistance.