> For the complete documentation index, see [llms.txt](https://docs.lithnet.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lithnet.io/okta-ma/supported-objects-and-operations.md).

# Supported objects and operations

What the management agent can and cannot do with Okta users and groups.

The management agent supports the `user` and `group` object types. Both use the Okta object `id` as the anchor.

## Users

| Operation               | Supported                                                  |
| ----------------------- | ---------------------------------------------------------- |
| Full import             | Yes                                                        |
| Delta import            | Yes                                                        |
| Create                  | Yes                                                        |
| Update profile          | Yes, for attributes the Okta user schema marks as writable |
| Activate on create      | Optional, with or without an Okta activation email         |
| Suspend and unsuspend   | Yes                                                        |
| Deactivate              | Yes                                                        |
| Permanently delete      | Optional                                                   |
| Set and change password | Yes                                                        |

The user schema is built from the base and custom attributes of the default Okta user profile.

## Groups

| Operation                   | Supported         |
| --------------------------- | ----------------- |
| Full import                 | Yes               |
| Delta import                | Yes               |
| Create                      | `OKTA_GROUP` only |
| Update name and description | `OKTA_GROUP` only |
| Add and remove members      | `OKTA_GROUP` only |
| Delete                      | `OKTA_GROUP` only |

`BUILT_IN` and `APP_GROUP` groups can be imported as read-only reference data. Okta or another application owns them, and the management agent will not write to them.

## OAuth scopes and the schema

With OAuth authentication, the scopes granted to the service app determine what MIM sees when it retrieves the schema. A read scope presents the object type as import-only, a manage scope adds the supported export operations, and an object type with no scope isn't presented at all. See [Creating the OAuth service app](/okta-ma/authentication/creating-the-oauth-service-app.md).

API-token authentication always presents both object types with all supported operations, because a token carries no scope information the connector can read. Select only the operations that the token's owning account is allowed to perform.

## Deletion and deactivation

The **User deprovisioning action** setting on the Global Parameters page changes both export and import behavior. Read this section before you design your deprovisioning rules.

With **Deactivate**, a staged delete deactivates the user in Okta. Deactivated users are not presented to MIM, so a delta import confirms the delete. The user still exists in Okta and has to be deleted or reactivated there.

With **Delete**, a staged delete deactivates and then permanently deletes the user. Deactivated users that still exist in Okta are imported normally. Only a full import can confirm the permanent delete, because a deleted object cannot be returned by any query.

Group deletes are always permanent and are only confirmed by a full import.

## Limitations

* The management agent cannot reactivate a deactivated Okta user. With the **Deactivate** setting the object leaves the connector space, so a later reprovision is exported as a create, which Okta rejects because the login is still in use. Reactivate the user in Okta first.
* Delta import cannot detect an object that was deleted outside MIM. Schedule a periodic full import.
* Selecting group `member` adds one membership query per imported group, and `availableFactors` and `enrolledFactors` each add one query per imported user.
* Okta rate limits apply to every import and export, and are shared with everything else using the org.
* Exports are not transactional. A create can succeed and a following activation, suspension, or membership change can fail. See [Imports and exports](/okta-ma/operations/imports-and-exports.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lithnet.io/okta-ma/supported-objects-and-operations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.