DynamoDB is a NoSQL, schemaless database. It functions—on the surface—in similar ways to other database-style data sources, such as Salesforce or Oracle. DynamoDB can be used for more freeform data needs within a Skuid page, and it actually allows for end users to create new fields on the fly.

Note that, while DynamoDB’s schemaless structure allows for flexible data management, it is intended for data as opposed to assets. For the storage of files, consider using S3.

For more general information, see Amazon’s Getting Started with Amazon DynamoDB.


AWS access permissions

When using AWS APIs, it is best practice to utilize strict and well-defined IAM policies so end users can only perform actions they have explicit access to.

Listed below are the permissions this data source type requires to properly function. Use this list to better define your IAM roles.

  • dynamodb:DeleteItem
  • dynamodb:DescribeTable
  • dynamodb:ListTables
  • dynamodb:PutItem
  • dynamodb:Query
  • dynamodb:Scan
  • dynamodb:UpdateItem

Creating an AWS authentication provider

Before configuring data sources within Skuid, you need to decide how you’ll authenticate to your AWS services using an IAM role. We recommend consulting your AWS administrator prior to making this decision.

Assume Role [[]]

This authentication method allows you to use the ARN of an assumable role instead of hard-coded AWS access keys. When a Skuid user makes a request using this authentication method, Skuid makes a secure server-side request to assume the configured role. If this request is successful, Skuid receives temporary access credentials, which Skuid caches until the credentials expire after 60 minutes.

Requests made through an assumed role are traceable via the AWS console. From there, you can see both the Skuid site and Skuid user who initiated the request, which provides AWS administrators full visibility into who requested access credentials and from what Skuid site.

Due to this method’s security and ease-of-management after initial setup, we typically recommend it over the access keys method. However, it does require some technical knowledge to configure. Be sure to read all of the instructions below.

Before you begin

Skuid can only access roles that have a defined path containing the string /skuid-assumable-role/ . This is different from the role’s name. Role paths can only be set when first created, so it isn’t possible to update an existing role with a new path.

In order to create a role with a path, you’ll need to use either the AWS IAM API or the AWS CLI.

The instructions below assume you are using AWS CLI (version 2) and that you’ve already configured an access key ID and secret access key for use with the CLI. Ensure these credentials have the iam:CreateRole permission. Command line examples are also tailored for Linux or macOS operating systems; commands for command line programs on Windows may differ.

Finally, because IAM roles require a trust relationship policy upon creation, you’ll need to save the JSON that Skuid provides when creating an authentication provider. Because of this you’ll need to navigate between your browser window, your computer’s file explorer, as well as the command line.

In Skuid

  1. From the Skuid navigation bar, navigate to Data Sources > Authentication Providers.
  2. Click Create.
  3. Configure the authentication provider’s basic properties:
    • Name: Enter a name, such as AWSAuth.
    • Authentication Method: AWS: Assume Role with ARN
  4. In the Trust Relationship Policy, click Copy to Clipboard.

This copied policy will enable your role to grant proper access to your Skuid site.


If you want this role to be assumable by multiple Skuid sites—for example a staging site and a production site, make the sts:ExternalId property’s value into an array of Skuid site Ids.

For example, change this key/value:

"sts:ExternalId": "09583eba-de0e-49d3-ae42-61b3927a61b1"

Into this:

"sts:ExternalId": [

Site IDs are accessible from Settings > Site > Profile.

On your local machine

  1. With the policy copied to your clipboard, paste the policy into a text editor.
  2. Save the file to an easily accessible directory (for example, your desktop) on your machine with a recognizable name and the JSON file extension, like trust-policy.json

In a command line interface

With the trust policy saved to your machine, you can now use the AWS CLI to create an assumable role.

  1. Open your command line program of choice and navigate to the directory containing your policy JSON file. For example, if you saved the file on your desktop:

    cd ~/Desktop
  2. Use the AWS CLI’s iam create-role command to create the role with the proper path value and trust relationship policy:

    aws iam create-role --role-name Skuid-S3-Access --path /skuid-assumable-role/ --assume-role-policy-document file://trust-policy.json


    While role-name can vary from this example, the path must contain /skuid-assumable-role/

    The CLI creates the role, outputting its ARN and other related metadata. Because of the configured path, your ARN should look similar to this: arn:aws:iam::1234567891011:role/skuid-assumable-role/Skuid-S3-Access.

  3. Copy this created ARN, either from the command line output or the AWS console.

In Skuid

  1. Return to the authentication provider window.
  2. Paste the copied ARN into the AWS Role ARN to assume field.
  3. Click Save.

Access Keys [[]]

This authentication method utilizes an Amazon Web Service (AWS) IAM role’s access keys to authenticate to an AWS system.

If you are not the manager of your AWS services, follow along with Amazon’s steps for creating access keys with your IT administrator. You’ll need to do the following:


  1. Create a new group and select the appropriate policies for that group.
    • These should align with your intended Skuid use. Ensure your access policies match the services (S3, DynamoDB, or SNS) you’ll be using.
  2. Create a new user in AWS Identity and Access Management (IAM) within the newly created group.
  3. Retrieve the access credentials generated for that user:
    • The secret access key is only displayed once, immediately after the access key is generated, and cannot be found later. Be sure to copy it to a safe place.

In Skuid

With your access credentials handy, you can now use them to configure a Skuid authentication provider that will work with all AWS data sources.

  1. Navigate to Configure > Data Sources > Authentication Providers.
  2. Click New Authentication Provider.
  3. Configure the authentication provider’s basic properties:
    • Name: Enter a name, such as AWSAuth.
    • Authentication Method: AWS: Access Keys
  4. Enter your IAM role’s credential information:
    • AWS Access Key Id: The access key ID to use when authenticating.
    • AWS Secret Access Key: The secret access key to use when authenticating.
  5. Click Save.

Creating a DynamoDB data source

  1. Navigate to Data Sources > Data Sources.
  2. Click Create.
  3. Select Amazon DynamoDB for Type.
  4. Enter an appropriate value for Name, such as AWS-ServiceName.
  5. Click Next.
  6. Select the previously configured AWS authentication provider.
  7. Select the AWS Region where the resources you need within Skuid reside. See AWS documentation on regions for more information.
  8. Click Save.

After creation, leave Use proxy disabled. The proxy does not currently support Amazon DynamoDB data sources.

Using the AWS DynamoDB data source

As DynamoDB is schemaless, it has some unique concepts you’ll need to know to use it properly within Skuid.

  • Model entities for the DynamoDB data source type are based on the tables in your DynamoDB instance. Because of that, you’ll need to create at least one table before you work with Dynamo within a Skuid page.
  • Once a model entity is selected, only the indexed fields are pulled in to Skuid (namely the primary and sort key, if defined). Other non-indexed fields must be added to the model manually, in a manner similar to adding UI-only fields. The Skuid field Id should match the field name in the Dynamo table.
  • Due to this schemaless nature, it is possible to create new fields for a table on the fly in Skuid. Simply click Add Field, and set your Field ID and Custom Label.
  • Items within DynamoDB are analogous to records within relational databases

Model Properties

  • Query by Index: Determines whether the model queries against a table’s primary index or a secondary index.

    • Primary Index: (Default) The model will query against the primary, default index of the chosen DynamoDB table.

    • Secondary Indexes: Any global or local secondary indexes associated with the chosen table will be listed by name. Selecting a secondary index will cause the model to query against the chosen index, meaning a different subset of data may be returned.


      Querying by a secondary index can have positive or negative impacts on your DynamoDB bill. Be sure to review AWS documentation on the concepts and configuration of secondary indexes.


As DynamoDB is schemaless—and its model entities are the tables created within the DynamoDB instance—there are no default conditions. However, Skuid admins can use conditions to create filters and limit data as with any other Skuid data object:

  • Text fields can be filtered using the following operators:
    • = or equals
    • != or does not equal
    • starts with
    • contains
    • does not contain
    • does not start with
  • Number fields can be filtered using the following operators:
    • = or equals
    • != or does not equal
    • > or greater than
    • >= or greater than or equal to
    • < or less than
    • <= or less than or equal to
  • If multiple specified values are set for a condition, a field can be filtered based on whether its value is in or not in the specified set of condition values.

However, while end users can filter on any field within a table, all users should be aware of DynamoDB’s query and scan behavior. To summarize, it is best practice to filter by key attributes when possible. This will use a query function rather than scanning every item in your table. If filtering by a non-key attribute is necessary, end users should first filter by a key attribute to avoid scanning the entire table for data.

These behaviors make a difference on your DynamoDB costs, so build your Skuid pages with this in mind and instruct your end users appropriately.


When trying to select a model entity, I see “An internal server error occurred.” [[]]

The IAM user associated with your AWS access credentials within your Skuid authentication provider probably does not have the appropriate permissions for the service you are accessing. Return to the AWS console and ensure your IAM policy settings are correct.

If your policy settings are correct, recreate your authentication provider with a new access key.

I do not see my secondary index available as an option for the Query by Index property. [[]]

There may be a caching issue with your index list. Try restarting your browser or, if all else fails, clearing your browser’s local storage.